[GNAP] Alice a J&J COVID vaccine

[Denis <[e-mail]>]

Adrian,

I changed the title of this thread since your are addressing a new topic 
that I am unable to understand.
Alice J&J vaccine is Alice's private information. For which reason would 
Bob ask Alice to provide an access token ?

Denis

> This is helpful, Denis.
>
> I will focus on "Then Bob asks to Alice to issue for him an 
> authorization to access the resource." and avoid using any hammers.
>
> Let's use something in the news and say the RS is a hospital that gave 
> Alice a J&J COVID vaccine. Alice identified herself to the hospital 
> with a number N. N could have been randomly chosen by Alice or the 
> hospital or N could be Alice's driver's license number right next to 
> her face photo. GNAP should probably deal with both cases.
>
> The hospital creates a digital credential that includes the J&J 
> vaccine name and lot number, N, a statement about how N was derived, 
> and a date. The hospital posts this credential at some resource URL, 
> protected by some access token requirement, and gives Alice the 
> "resource URL" instead of or along with a paper vaccination card with 
> the same information as the resource.
>
> When Bob asks Alice for an access token, Bob makes a request to Alice 
> and she can either:
> A - Give Bob the "resource URL" and let him try his luck turning this 
> into an access token somewhere,
> B - Go to the hospital portal and authenticate somehow and grab an 
> access token that she can return to Bob,
> C - Give Bob an access token for the resource URL based on some 
> signature that is trusted by the hospital.
>
> When Bob gets the resource, it will include N along with the 
> hospital's statement about how N was derived. Bob can decide what to 
> do next.
>
> Adrian
>
>
> On Mon, Mar 29, 2021 at 9:54 AM Denis <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Adrian,
>
>     Thank you for the scenario. You certainly know the following sentence:
>
>         "When the only tool you have is a hammer, every problem looks
>         like a nail".
>
>     Similarly:  "When the only tool you have is an AS, every problem
>     looks like an access token issued by an AS".
>
>     Let us start with exactly the same sentence that explains the goal:
>
>         Let Alice be the RO and subject of a resource. at a RS. Let
>         Bob be a party, not Alice, that seeks authorization to access
>         the resource using an access token.
>
>     Then Bob asks to Alice to issue for him an authorization to access
>     the resource.
>     Alice, as the RO of the resource, request from the RS an "/access
>     token/"  which is an (unsigned) data structure which contains:
>     a read permission on some Alice's photo directory, associated with
>     a large random number /chosen by the RS/.
>
>     Note that a validity period will also be associated in practice,
>     but this is a minor detail for the demonstration.
>
>     Alice sends back to Bob the "/access token/" issued by the RS.
>
>     *Bob looks inside the access token* to make sure that it
>     corresponds to what he requested to Alice, i.e. a read permission
>     on some Alice's photo directory.
>
>     If the content is fine, Bob presents to the RS the large random
>     number associated together with an API GET for some sub-set of the
>     photos contained in Alice's directory.
>
>     Since the RS recognizes the large random number and that the GET
>     API is valid according to the "access token" memorized by the RS
>     authorization set by Alice as a RO,
>     the access is granted.
>
>     In this example, the RS will not know who is reading the photo
>     directory. So Bob can transmit the "access token" to someone else
>     during its validity period, which may be a desirable feature.
>     Note that it is also possible to allow Bob only to access Alice's
>     directory. For simplicity, this alternative is not explained.
>
>     In the mean time, I solved the answer of your question which was:"
>     /How Bob discovered the AS to make the request to is unclear to me
>     for the time being/".
>     The request to your question is also unclear to me for the time
>     being, but since there is no AS involved, Bob does not need to
>     discover any AS. :-)
>
>     I am quite sure that someone else will be able to describe one or
>     more scenarios "/using an AS as an hammer/", but is is very likely
>     that in such a case,
>     the AS will be able know that Bob is rather likely to access in a
>     short time some photos placed in the Alice's directory of photo
>     hosted on that RS. /
>     This may be a privacy concern for Bob/.
>
>     Of course, in addition, the AS and the RS must establish some
>     prior relationships, etc ...
>
>     However, all the discussion above is outside the scope of this
>     initial thread which is: Relationship between Authentication and
>     Authorization ?
>     If you want to continue the discussion on the topic you mentioned,
>     that's fine with me, but please change the title of this thread.
>
>     Denis
>
>
>>     Hi Denis,
>>
>>     I don’t understand your privacy issue, and I would like to try.
>>
>>     Let Alice be the RO and subject of a resource. at a RS. Let Bob
>>     be a party, not Alice, that seeks authorization to access the
>>     resource using an access token.
>>
>>     Bob has discovered the resource somehow that is out of band for
>>     GNAP. (Maybe Alice sent Bob a pointer to the resource in an email).
>>
>>     Bob makes a request for the resource at some AS. The request
>>     includes the pointer that Bob discovered to the resource, some
>>     attributes or claims about Bob, and maybe a reason for the request.
>>
>>     How Bob discovered the AS to make the request to is unclear to me
>>     for the time being. Maybe Bob discovered the AS along with the
>>     resource. (e.g The resource is a DID and the AS is a service
>>     endpoint or mediator to an AS in that DID.)
>>
>>     Given the scenario above, who’s privacy interest are you
>>     primarily concerned about? Alice or Bob?
>>
>>     Adrian
>>
>>     On Mon, Mar 29, 2021 at 6:39 AM Denis <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         Hi  Justin,
>>
>>         Since your response only deals with the AS, but not the RS
>>         nor the RO, it is not a response to my question which was:
>>
>>             How will a RS or a RO be bootstrapped for working with a
>>             GNAP "sub" claim or a "sub_id" claim ?
>>
>>>         The subject identifier is whatever identifier the AS knows
>>>         the subject as. If they log in using only a FIDO token and
>>>         the AS asserts that key value as the identifier, then that’s
>>>         what it will be. If they sign up with an email address or
>>>         make a username or get assigned a random number, that’s what
>>>         it will be. Or they could sign up using any number of those
>>>         and the AS still assigns them a random value, because it’s
>>>         always the AS that determines which value to assign the number.
>>
>>         When looking at Section 3.2 (Access Tokens), the client (and
>>         hence the end-user) has currently /no practical way/ to
>>         indicate which of its attributes should be placed into an
>>         access token,
>>         The only reference within Section 3.2 is pointing to the
>>         empty Section 12. Among the many examples, there is not a
>>         single example that addresses the case of attributes being
>>         placed into an access token.
>>
>>         Nevertheless, it seems that in your opinion, only the AS, but
>>         NOT the client (and hence the end-user), SHALL have control
>>         at all of what kind of /subject identifier/ claim will be
>>         placed inside the access token.
>>
>>         Then after, invoking the postulate "the access token SHALL
>>         remain opaque to the client (and hence the end-user)", it
>>         seems that in your opinion, the end-user SHALL have no way to
>>         verify
>>         whether its privacy has been respected. If this is not an
>>         architecture built along "spy by design" principles, I don't
>>         know what else it might be.
>>
>>         It is important to re-read two of the current definitions:
>>
>>             *Privilege*: right *or attribute* associated with a subject.
>>
>>             *Access Toke*n: data artifact representing a set of
>>             rights *a**nd/or attributes*.
>>
>>         In the current draft, the case of rights is indeed addressed
>>         while *the case of attributes is fully ignored*.
>>
>>>         The RS is not involved in any subject information. Identity
>>>         APIs, like OpenID Connect’s UserInfo Endpoint, are out of
>>>         scope for GNAP.
>>
>>         Really ? Do you mean that an access token should not contain
>>         a "sub" claim nor a "sub_id" claim  and if it does, the RS
>>         SHALL ignore such claims ?
>>
>>         In the "OAuth Access Token JWT Profile", there is the
>>         following sentence in Section 6 (Privacy Considerations) :
>>
>>                This profile mandates the presence of the "sub" claim
>>             in every JWT
>>                access token, making it possible for resource servers
>>             to rely on that
>>                information for performing tasks such as correlating
>>             incoming
>>                requests with /data stored locally for the
>>             authenticated principal/.
>>
>>         This sentence clearly makes a relationship between the value
>>         present in the "sub" claim and "/data stored locally for the
>>         //*authenticated *//principal/".
>>
>>         However, note that the "OAuth Access Token JWT Profile" fails
>>         to allow the client (and hence the end-user) to control his
>>         privacy, since the client
>>         cannot choose which value will be placed in the "sub" claim
>>         and also because access tokens are considered to be opaque
>>         for the clients in OAuth.
>>>         If there is a subject identifier either included in or
>>>         referenced by the access token, that is /up to any
>>>         agreements between the AS and RS/
>>>         that lead to the ability of the AS to create the tokens the
>>>         RS can trust. All of this is outside the scope of the core
>>>         GNAP protocol and invisible to the client.
>>
>>         You are using the following words "/up to any agreements
>>         between the AS and RS/". This mandates prior agreements
>>         between ASs and RSs
>>         and in such a case the architecture will be non-scalable over
>>         the Internet. The trust relationship between a RS and an AS
>>         is unilateral:
>>         The RS trusts the AS to issue appropriate access tokens
>>         corresponding to the requests of its clients.
>>
>>         From an end-user point of view, if there cannot be
>>         *transparency* because of the access token opacity,**then
>>         there cannot be *confidence *about GNAP .
>>
>>         Denis
>>
>>
>>>          — Justin
>>>
>>>>         On Mar 26, 2021, at 1:27 PM, Denis <[e-mail]
>>>>         <mailto:[e-mail]>> wrote:
>>>>
>>>>         Hi Justin,
>>>>
>>>>         Let me rephrase the last question: How will a RS or a RO be
>>>>         bootstrapped for working with a GNAP "sub" claim or a
>>>>         "sub_id" claim ?
>>>>
>>>>         Denis
>>>>
>>>>>         GNAP doesn’t have anything too say about anybody
>>>>>         authenticating directly to the RS. If that happens, it’s
>>>>>         out of the view and out of scope of GNAP.
>>>>>
>>>>>          — Justin
>>>>>
>>>>>>         On Mar 26, 2021, at 1:06 PM, Denis <[e-mail]
>>>>>>         <mailto:[e-mail]>> wrote:
>>>>>>
>>>>>>         Hi everybody,
>>>>>>
>>>>>>         The content of this thread has nothing to do any more
>>>>>>         with its original title which was: "Will GNAP support
>>>>>>         Zero Trust Architecture?"
>>>>>>         Since I am going to use some sentences of this thread to
>>>>>>         open a new topic, I changed the title of this thread into :
>>>>>>         "Relationship between Authentication and Authorization ?"
>>>>>>
>>>>>>         At the moment, I got the impression that nobody agrees
>>>>>>         any more about *what GNAP is or is not, what it should
>>>>>>         address and what it should not address*.
>>>>>>         The components of the model are becoming more numerous
>>>>>>         and hazy. A new terminology is sometimes being used, but
>>>>>>         is not yet present in the last published draft.
>>>>>>
>>>>>>         I still can't understand any of the new terms that are
>>>>>>         being used (*AS-RS* and *AS-RO*), _which are still left
>>>>>>         undefined_.
>>>>>>
>>>>>>         The last exchanges look more as conversations between
>>>>>>         workers during the construction of the Babel tower.
>>>>>>
>>>>>>         Last year, my first remark was to mention that a section
>>>>>>         or an Annex explaining the common points and the
>>>>>>         differences with OAuth 2.0
>>>>>>         would be useful. Such section or Annex still does not exist.
>>>>>>
>>>>>>         Justin wrote:
>>>>>>
>>>>>>             /If an RS allows a username/password HTTP Basic auth
>>>>>>             in addition to accepting access tokens, it can do so,
>>>>>>             but //
>>>>>>             //GNAP doesn’t have anything to say about the Basic
>>>>>>             auth use, or even its relation to any access tokens
>>>>>>             or RO’s or anything else./
>>>>>>
>>>>>>         Let us split the end of this sentence into two parts:
>>>>>>
>>>>>>         "/GNAP doesn’t have anything //to say about the Basic
>>>>>>         auth use/":  If an authentication exchange  is necessary,
>>>>>>         the draft document should describe, for completeness,
>>>>>>         the HTTP error code that will be returned.
>>>>>>
>>>>>>         "/or even its relation to any access tokens or RO’s or
>>>>>>         anything else/". Let us suppose that a RS supports FIDO
>>>>>>         as an authentication mechanism to authenticate its end-users.
>>>>>>         FIDO provides the major advantage that, for every RS, a
>>>>>>         different identifier is used by every end-user. This
>>>>>>         prevents end-users accounts correlations between RSs by
>>>>>>         using
>>>>>>         such identifiers. In practice, a FIDO identifier is a
>>>>>>         pseudonym.
>>>>>>
>>>>>>         At this very moment, the RS is able to identify and
>>>>>>         authenticate its end-users using FIDO pseudonyms. Now,
>>>>>>         let us raise the following question:
>>>>>>
>>>>>>         How will a RS be bootstrapped for working with a GNAP
>>>>>>         "sub" claim or a "sub_id" claim, whereas FIDO is already
>>>>>>         being used ?
>>>>>>
>>>>>>         Denis
>>>>>>
>>>>>>
>>>>>>>         Adrian,
>>>>>>>
>>>>>>>         I disagree, I believe that what I have laid out is
>>>>>>>         exactly separating the concerns into working components.
>>>>>>>
>>>>>>>         Like OAuth before it, GNAP is a protocol negotiate
>>>>>>>         access for a client instance to an RS, using an AS as
>>>>>>>         the facilitator of that delegated negotiation. (Unlike
>>>>>>>         OAuth, it’s importantly also for negotiating user
>>>>>>>         information to the client directly from the AS with no
>>>>>>>         RS involved, but that’s an aside for the purposes of our
>>>>>>>         conversation here).
>>>>>>>
>>>>>>>         If a particular GNAP RS also allows other kinds of
>>>>>>>         processes to enable access to it, that is completely
>>>>>>>         fine, but outside of GNAP. If an RS allows a
>>>>>>>         username/password HTTP Basic auth in addition to
>>>>>>>         accepting access tokens, it can do so, but GNAP doesn’t
>>>>>>>         have anything to say about the Basic auth use, or even
>>>>>>>         its relation to any access tokens or RO’s or anything
>>>>>>>         else. If an RS accepts structured access tokens signed
>>>>>>>         by trusted keys that don’t come from an AS through a
>>>>>>>         negotiated request — again, that’s fine, but GNAP is
>>>>>>>         silent about the RS doing that. If the RS acts as “its
>>>>>>>         own AS” then it’s really just an RS and an AS living in
>>>>>>>         the same box. Again, that’s fine, and super common with
>>>>>>>         OAuth today.
>>>>>>>
>>>>>>>         GNAP is solving the problem of connecting the client to
>>>>>>>         the RS through means of an AS. Other solutions are
>>>>>>>         possible and many of them can be deployed right
>>>>>>>         alongside, but that’s not the corner of the world that
>>>>>>>         GNAP is solving. GNAP should be concerned about how
>>>>>>>         these other technologies can be used alongside it. I
>>>>>>>         think there’s a lot of room for the things that you’re
>>>>>>>         talking about, and more importantly for solving the use
>>>>>>>         cases that you’re bringing. But GNAP should be more than
>>>>>>>         a single-point solution, and so we need to balance these
>>>>>>>         concerns. The conceptual framework of an AS that takes
>>>>>>>         in lots of different information and spits out access
>>>>>>>         tokens is exactly the abstraction layer that is
>>>>>>>         necessary for making these use cases interoperable.
>>>>>>>
>>>>>>>          — Justin
>>>>>>>
>>>>>>>>         On Mar 26, 2021, at 8:30 AM, Adrian Gropper
>>>>>>>>         <[e-mail]
>>>>>>>>         <mailto:[e-mail]>> wrote:
>>>>>>>>
>>>>>>>>         @Justin, there’s no separation of concerns here. No
>>>>>>>>         partition between processor and controller. No data
>>>>>>>>         minimization. And, I see no obvious reason to make this
>>>>>>>>         the core of GNAP.
>>>>>>>>
>>>>>>>>         The one thing we can probably all agree on is that
>>>>>>>>         there’s only one RS and one RO.
>>>>>>>>
>>>>>>>>         The core of GNAP, in my opinion, can be built and
>>>>>>>>         explained around this simple design. The RS is a
>>>>>>>>         processor. The RO is a controller. The RS bears only
>>>>>>>>         security responsibility. The RS bears no privacy
>>>>>>>>         responsibility. The RO delegates this to the RS but
>>>>>>>>         this is not authorization as the A in GNAP.
>>>>>>>>
>>>>>>>>         The RO retains all rights to delegate within the scope
>>>>>>>>         of things that the RS is willing to support using
>>>>>>>>         various token formats and endpoint options. Some of
>>>>>>>>         these options may do all sorts of things for all sorts
>>>>>>>>         of clients and user-agents  but these are options.
>>>>>>>>
>>>>>>>>         For example, if a request comes to the RS that is not
>>>>>>>>         in the form of an access token, then it either gets
>>>>>>>>         sent to the RO or their agent, or it gets logged and
>>>>>>>>         dumped. One such option, common in healthcare, is
>>>>>>>>         “Break the Glass” where the RS is acting as an
>>>>>>>>         authorization server because the user-agent is making a
>>>>>>>>         request instead of presenting an access token. GNAP can
>>>>>>>>         offer this as an option but it is not our core.
>>>>>>>>
>>>>>>>>         Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>         On Fri, Mar 26, 2021 at 7:15 AM Justin Richer
>>>>>>>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>
>>>>>>>>             I have a big problem with this line:
>>>>>>>>
>>>>>>>>             > the RS and AS-RS only see access tokens. The
>>>>>>>>             requests (from RO') that resulted in an access
>>>>>>>>             token are none of their business.
>>>>>>>>
>>>>>>>>             In the trust model we’ve been discussing, the
>>>>>>>>             requests that result in access tokens are *solely
>>>>>>>>             the business of AS-RS*, since AS-RS is the only
>>>>>>>>             entity that’s allowed, and trusted by the RS, to
>>>>>>>>             create access tokens for the RS. That is its entire
>>>>>>>>             job, the entire reason it exists in the system. By
>>>>>>>>             definition the party generating tokens for use at
>>>>>>>>             the RS is the AS for that RS, I don’t care how you
>>>>>>>>             deploy it. If RO wants to give access to someone
>>>>>>>>             else (who isn’t an “RO" anymore, they’re another
>>>>>>>>             end-user), then that end user’s client software
>>>>>>>>             will need to talk to AS-RS to get its own access
>>>>>>>>             token.
>>>>>>>>
>>>>>>>>             Now here’s the trick: when the end user’s client
>>>>>>>>             instance talks to AS-RS, that does NOT mean that
>>>>>>>>             AS-RS needs to know all the details and policy
>>>>>>>>             reasons that it should give an access token to that
>>>>>>>>             client instance. It doesn’t even need to know the
>>>>>>>>             existence of another end user. It doesn’t need
>>>>>>>>             identity, it doesn’t need policy. Sure, it COULD
>>>>>>>>             handle all of that internally, and many will, but
>>>>>>>>             the protocol doesn’t demand it.
>>>>>>>>
>>>>>>>>             This means that the first client instance, the one
>>>>>>>>             that gets the access token, can also be given
>>>>>>>>             something alongside the access token that it can
>>>>>>>>             then hand to another piece of software (or to a
>>>>>>>>             person to hand eo their piece of software). This
>>>>>>>>             artifact is not an access token. This artifact
>>>>>>>>             could be something structured that the client
>>>>>>>>             understands, and can make derivatives of, and
>>>>>>>>             present back to the AS-RS for getting new access
>>>>>>>>             tokens. There could be multiple different flavors
>>>>>>>>             of this kind of artifact for different kinds of
>>>>>>>>             environments and groups. But what they all have in
>>>>>>>>             common is that they can potentially be used to
>>>>>>>>             request more access tokens within some context at
>>>>>>>>             the AS-RS.
>>>>>>>>
>>>>>>>>              — Justin
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>             On Mar 25, 2021, at 5:50 PM, Adrian Gropper
>>>>>>>>>             <[e-mail]
>>>>>>>>>             <mailto:[e-mail]>> wrote:
>>>>>>>>>
>>>>>>>>>             My issue is with Alan's:
>>>>>>>>>
>>>>>>>>>                 "7. Another user agent (RO') can contact any
>>>>>>>>>                 holder of the access token or the service's
>>>>>>>>>                 policy agent (AS-RS) to get a delegated access
>>>>>>>>>                 token."
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>             I would prefer "7A.Another user agent (RO') can
>>>>>>>>>             contact any holder of the access token." by
>>>>>>>>>             default so that the AS-RS does not see the
>>>>>>>>>             requests. In other words, the RS and AS-RS only
>>>>>>>>>             see access tokens. The requests (from RO') that
>>>>>>>>>             resulted in an access token are none of their
>>>>>>>>>             business.
>>>>>>>>>
>>>>>>>>>             The reality is that RO' can discover a resource RS
>>>>>>>>>             and can share whatever information with RS-AS they
>>>>>>>>>             want and the RO may not even know about it unless
>>>>>>>>>             the RS decides to let them know somehow. This
>>>>>>>>>             seems to be a drawback of the capabilities approach.
>>>>>>>>>
>>>>>>>>>             In terms of privacy and control, I, as the RO,
>>>>>>>>>             want a contract with the RS that says that I or my
>>>>>>>>>             agent (AS-RO) must sign an access token. This is a
>>>>>>>>>             fundamental audit requirement. Without it, a rogue
>>>>>>>>>             RS and AS-RS can do all sorts of things and the RO
>>>>>>>>>             would never know. I understand that a rogue RS
>>>>>>>>>             might not support an honest contemporaneous log of
>>>>>>>>>             access tokens presented so there's a trust issue
>>>>>>>>>             here that I seems unavoidable unless I specify in
>>>>>>>>>             my RO-RS contract that they use a separate
>>>>>>>>>             contemporaneous log such as AS-RO for every access
>>>>>>>>>             token presented and risk being sued if they
>>>>>>>>>             process an access token without also updating the
>>>>>>>>>             separate log.
>>>>>>>>>
>>>>>>>>>             - Adrian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>             On Thu, Mar 25, 2021 at 1:22 PM Alan Karp
>>>>>>>>>             <[e-mail] <mailto:[e-mail]>>
>>>>>>>>>             wrote:
>>>>>>>>>
>>>>>>>>>                 Justin Richer <[e-mail]
>>>>>>>>>                 <mailto:[e-mail]>> wrote:
>>>>>>>>>
>>>>>>>>>                     Hi Alan,
>>>>>>>>>
>>>>>>>>>                     In all of my discussion, and in the spec
>>>>>>>>>                     itself, the RO is the :entity: in charge
>>>>>>>>>                     of approving rights. They’re probably a
>>>>>>>>>                     person. It might be software that makes a
>>>>>>>>>                     policy decision in some way, or a
>>>>>>>>>                     corporate entity, or something like that.
>>>>>>>>>                     But it’s not assumed to be a computational
>>>>>>>>>                     agent in the terms of the protocol itself.
>>>>>>>>>                     Would that recast what you’re saying below?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                 Hmmm.  I guess not. It's just that the person
>>>>>>>>>                 would be using some UI to express their
>>>>>>>>>                 decisions to what I called the user agent. 
>>>>>>>>>                 That model fits in very nicely with what we
>>>>>>>>>                 did with Polaris, our virus safe computing
>>>>>>>>>                 environment for Windows XP,
>>>>>>>>>                 https://dl.acm.org/doi/10.1145/1151030.1151033
>>>>>>>>>                 <https://dl.acm.org/doi/10.1145/1151030.1151033>.
>>>>>>>>>                 The person would click on the icon for a Word
>>>>>>>>>                 file, and an instance of Word would open with
>>>>>>>>>                 only the permission needed to edit that one
>>>>>>>>>                 file.  Same thing here. The client could ask
>>>>>>>>>                 for permission to use the resource, or
>>>>>>>>>                 permission could be granted implicitly when
>>>>>>>>>                 the user selects a resource associated with a
>>>>>>>>>                 specific client.
>>>>>>>>>
>>>>>>>>>                 --------------
>>>>>>>>>                 Alan Karp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                 On Thu, Mar 25, 2021 at 9:53 AM Justin Richer
>>>>>>>>>                 <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>>
>>>>>>>>>                     Hi Alan,
>>>>>>>>>
>>>>>>>>>                     In all of my discussion, and in the spec
>>>>>>>>>                     itself, the RO is the :entity: in charge
>>>>>>>>>                     of approving rights. They’re probably a
>>>>>>>>>                     person. It might be software that makes a
>>>>>>>>>                     policy decision in some way, or a
>>>>>>>>>                     corporate entity, or something like that.
>>>>>>>>>                     But it’s not assumed to be a computational
>>>>>>>>>                     agent in the terms of the protocol itself.
>>>>>>>>>                     Would that recast what you’re saying below?
>>>>>>>>>
>>>>>>>>>                      — Justin
>>>>>>>>>
>>>>>>>>>>                     On Mar 25, 2021, at 12:36 PM, Alan Karp
>>>>>>>>>>                     <[e-mail]
>>>>>>>>>>                     <mailto:[e-mail]>> wrote:
>>>>>>>>>>
>>>>>>>>>>                     There seems to be some confusion about
>>>>>>>>>>                     how AS-RO comes into the picture,
>>>>>>>>>>                     probably because of the "AS" part. I'm
>>>>>>>>>>                     going to try to clear up that confusion
>>>>>>>>>>                     by more carefully explaining what I mean.
>>>>>>>>>>
>>>>>>>>>>                     I'm assuming that RO is a computational
>>>>>>>>>>                     agent representing the person who is the
>>>>>>>>>>                     resource owner, something called the
>>>>>>>>>>                     "user agent" in operating systems lingo. 
>>>>>>>>>>                     I'm also assuming that it's possible to
>>>>>>>>>>                     do delegation, either locally or by token
>>>>>>>>>>                     exchange with AS-RS.  All delegations are
>>>>>>>>>>                     potentially sub-scoped, but you may also
>>>>>>>>>>                     want to delegate with full scope to have
>>>>>>>>>>                     a separately revocable access token.
>>>>>>>>>>
>>>>>>>>>>                       Here's an example of how things work in
>>>>>>>>>>                     a capability oriented system.
>>>>>>>>>>
>>>>>>>>>>                      1. Someone, the service owner, creates a
>>>>>>>>>>                         service.
>>>>>>>>>>                      2. The service owner contracts with an
>>>>>>>>>>                         policy agent (AS-RS) to create and
>>>>>>>>>>                         manage access tokens for that service
>>>>>>>>>>                         (RS).
>>>>>>>>>>                      3. A person wishing to create a resource
>>>>>>>>>>                         at RS uses their user agent (RO) to
>>>>>>>>>>                         contact the service owner's policy
>>>>>>>>>>                         agent (AS-RS) and gets back an access
>>>>>>>>>>                         token for that resource.
>>>>>>>>>>                      4. That user agent (RO) can
>>>>>>>>>>                          1. use that access token to invoke
>>>>>>>>>>                             the resource, or
>>>>>>>>>>                          2. delegate an access token to a
>>>>>>>>>>                             client of the user agent's (RO)
>>>>>>>>>>                             choice, or
>>>>>>>>>>                          3. contract with a policy agent
>>>>>>>>>>                             (AS-RO) to manage those
>>>>>>>>>>                             delegations on behalf of the user
>>>>>>>>>>                             agent (RO), or
>>>>>>>>>>                          4. specify a policy with the
>>>>>>>>>>                             service's policy agent (AS-RS).
>>>>>>>>>>                      5. A client can contact any holder of
>>>>>>>>>>                         the access token (the user agent (RO)
>>>>>>>>>>                         or its policy agent (AS-RO)) or the
>>>>>>>>>>                         service's policy agent (AS-RS) to get
>>>>>>>>>>                         a delegated access token.
>>>>>>>>>>                      6. That client can delegate that token
>>>>>>>>>>                         to another client.
>>>>>>>>>>                      7. Another user agent (RO') can contact
>>>>>>>>>>                         any holder of the access token or the
>>>>>>>>>>                         service's policy agent (AS-RS) to get
>>>>>>>>>>                         a delegated access token.
>>>>>>>>>>                      8. The other user agent (RO') can
>>>>>>>>>>                          1. use that access token to invoke
>>>>>>>>>>                             the resource, or
>>>>>>>>>>                          2. delegate it to a client of its
>>>>>>>>>>                             choice, or
>>>>>>>>>>                          3. contract with a policy agent
>>>>>>>>>>                             (AS-RO') of its choosing to
>>>>>>>>>>                             manage those delegations on its
>>>>>>>>>>                             behalf, or
>>>>>>>>>>                          4. specify a policy with the
>>>>>>>>>>                             service's policy agent (AS-RS).
>>>>>>>>>>                      9. and so on
>>>>>>>>>>
>>>>>>>>>>                     When any of these computational agents,
>>>>>>>>>>                     user agents (ROs) or clients acting on
>>>>>>>>>>                     their behalf, invokes the resource, AS-RS
>>>>>>>>>>                     verifies that the access token is a valid
>>>>>>>>>>                     delegation, i.e., proper sub-scoping,
>>>>>>>>>>                     hasn't been revoked, and that it
>>>>>>>>>>                     authorizes the request being made before
>>>>>>>>>>                     telling the service (RS) to honor the
>>>>>>>>>>                     request.  At no point does the service's
>>>>>>>>>>                     policy agent (AS-RS) know which
>>>>>>>>>>                     computational agent did any particular
>>>>>>>>>>                     delegation. (Token exchange can be done
>>>>>>>>>>                     as anonymously as possible.)  In
>>>>>>>>>>                     particular, the policy agents (AS-RO)
>>>>>>>>>>                     need not be the same, or even compatible
>>>>>>>>>>                     with, the service's policy agent
>>>>>>>>>>                     (AS-RS).  GNAP specifies the protocol
>>>>>>>>>>                     between requesters, invokers, delegators
>>>>>>>>>>                     (for token exchange) of tokens and
>>>>>>>>>>                     AS-RS.  That protocol need not be used
>>>>>>>>>>                     between user agents (RO), clients, or
>>>>>>>>>>                     other policy agents (AS-RO), but it is
>>>>>>>>>>                     likely to be.
>>>>>>>>>>
>>>>>>>>>>                      -------------
>>>>>>>>>>                     Alan Karp
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     On Thu, Mar 25, 2021 at 5:45 AM Justin
>>>>>>>>>>                     Richer <[e-mail]
>>>>>>>>>>                     <mailto:[e-mail]>> wrote:
>>>>>>>>>>
>>>>>>>>>>                         The way I’m thinking about Adrian’s
>>>>>>>>>>                         use case is that what we’re calling
>>>>>>>>>>                         the “AS-RO” isn’t an “AS” in the
>>>>>>>>>>                         traditional OAuth/GNAP sense, at
>>>>>>>>>>                         least not exactly. This is the agent
>>>>>>>>>>                         that the RO can use to set policies
>>>>>>>>>>                         and manage consent on their behalf,
>>>>>>>>>>                         and I’ve been arguing that it fits
>>>>>>>>>>                         better into this vaguely-defined
>>>>>>>>>>                         “interaction component” aspect of the
>>>>>>>>>>                         current AS definition, and it’s not
>>>>>>>>>>                         currently separated from the AS
>>>>>>>>>>                         definition. The “AS-RS” maps to what
>>>>>>>>>>                         we’d call the “AS” in OAuth/GNAP
>>>>>>>>>>                         traditionally, it’s what the RS
>>>>>>>>>>                         trusts to issue tokens. In
>>>>>>>>>>                         traditional OAuth the AS-RO and AS-RS
>>>>>>>>>>                         are always the same thing, from a
>>>>>>>>>>                         functional protocol perspective. An
>>>>>>>>>>                         important point here is that from a
>>>>>>>>>>                         client’s perspective, they’re only
>>>>>>>>>>                         talking to the AS-RS since that’s
>>>>>>>>>>                         where the client gets its tokens,
>>>>>>>>>>                         because at the end of the day the
>>>>>>>>>>                         client just wants to call the API at
>>>>>>>>>>                         the RS and doesn’t care how that
>>>>>>>>>>                         happens (from a protocol standpoint).
>>>>>>>>>>
>>>>>>>>>>                         Note well: Even thought I don’t
>>>>>>>>>>                         believe that “AS-RO” is an
>>>>>>>>>>                         authorization server at all, I’m
>>>>>>>>>>                         going to keep using that term below
>>>>>>>>>>                         for consistency with previous discussion.
>>>>>>>>>>
>>>>>>>>>>                         So we have these fundamental
>>>>>>>>>>                         relationships around getting the
>>>>>>>>>>                         client to access the RS:
>>>>>>>>>>
>>>>>>>>>>                         1. RS trusts AS-RS to issue tokens
>>>>>>>>>>                         that RS will accept, validate, and
>>>>>>>>>>                         process for requests from client
>>>>>>>>>>                         2. Client trusts AS-RS to issue
>>>>>>>>>>                         tokens that client can use at RS
>>>>>>>>>>                         3. RO trusts RS to protect RO’s api
>>>>>>>>>>                         through delegated access
>>>>>>>>>>
>>>>>>>>>>                         On top of that, we’ve got some
>>>>>>>>>>                         additional aspects that we’re discussing:
>>>>>>>>>>
>>>>>>>>>>                         4. RO trusts AS-RO to manage RO’s
>>>>>>>>>>                         policies at runtime
>>>>>>>>>>                         5. AS-RS trusts AS-RO to assert RO’s
>>>>>>>>>>                         policies for access to RS
>>>>>>>>>>                         6. Client trusts whatever AS-RS sends
>>>>>>>>>>                         client to deal with, including
>>>>>>>>>>                         possibly RO-AS at runtime, because of (2)
>>>>>>>>>>
>>>>>>>>>>                         What I have been saying is that 4/5/6
>>>>>>>>>>                         are optional details of how RS-AS
>>>>>>>>>>                         runs things, and I think this also
>>>>>>>>>>                         maps with Adrian’s view of choice,
>>>>>>>>>>                         since if my RS’s AS-RS doesn’t allow
>>>>>>>>>>                         me to plug in my own AS-RO then I
>>>>>>>>>>                         would be motivated to pick a
>>>>>>>>>>                         different RS who’s AS-RS lets me do
>>>>>>>>>>                         just that. The same way I’d pick a
>>>>>>>>>>                         different RS if their surrounding
>>>>>>>>>>                         services didn’t accept my preferred
>>>>>>>>>>                         federation login and I didn’t want to
>>>>>>>>>>                         make another account. Of course,
>>>>>>>>>>                         market forces being as they are, I
>>>>>>>>>>                         might not have much of an actionable
>>>>>>>>>>                         choice in RS, but GNAP can’t change
>>>>>>>>>>                         that.
>>>>>>>>>>
>>>>>>>>>>                         What we can do is make it possible
>>>>>>>>>>                         for AS-RS to talk to AS-RO, both in
>>>>>>>>>>                         philosophy of the protocol design and
>>>>>>>>>>                         in concrete hooks to support (6) above.
>>>>>>>>>>
>>>>>>>>>>                         Separately, we can approach the issue
>>>>>>>>>>                         of making 1/2 above more dynamic.
>>>>>>>>>>                         This was UMA2’s “federated
>>>>>>>>>>                         authorization” approach, and is
>>>>>>>>>>                         behind a lot of the “bring your own
>>>>>>>>>>                         AS” models out there. The problem
>>>>>>>>>>                         with these is that we know from many
>>>>>>>>>>                         years of experience that most RS’s
>>>>>>>>>>                         aren’t interested in doing anything
>>>>>>>>>>                         of the sort.
>>>>>>>>>>
>>>>>>>>>>                         So with GNAP we can instead allow
>>>>>>>>>>                         4/5/6 to vary in a predictable and
>>>>>>>>>>                         consistent way, letting the RS keep
>>>>>>>>>>                         control over 1/2, thereby enabling
>>>>>>>>>>                         choice in (3). We don’t have to be
>>>>>>>>>>                         the ones who define the all of the
>>>>>>>>>>                         details of every permutation of (5)
>>>>>>>>>>                         to enable this, though. Some of this
>>>>>>>>>>                         is going to be configuration out of
>>>>>>>>>>                         band, some of it’s going to be
>>>>>>>>>>                         communication at runtime. This is
>>>>>>>>>>                         where VC’s, ZCAPs, CHAPI, DIDComm,
>>>>>>>>>>                         FIDO, and a whole swath of other tech
>>>>>>>>>>                         can come in and help out. I don’t
>>>>>>>>>>                         think we need to put all the details
>>>>>>>>>>                         for using these into core, nor do I
>>>>>>>>>>                         think we’ll pull of The Great And
>>>>>>>>>>                         Ultimate Abstraction for using these
>>>>>>>>>>                         and other approaches. But we can at
>>>>>>>>>>                         least start talking about “AS-RS” in
>>>>>>>>>>                         such a way that it no longer assumes
>>>>>>>>>>                         it’s always the same party dealing
>>>>>>>>>>                         with the RO directly.
>>>>>>>>>>
>>>>>>>>>>                          — Justin
>>>>>>>>>>
>>>>>>>>>>>                         On Mar 25, 2021, at 6:40 AM, Fabien
>>>>>>>>>>>                         Imbault <[e-mail]
>>>>>>>>>>>                         <mailto:[e-mail]>>
>>>>>>>>>>>                         wrote:
>>>>>>>>>>>
>>>>>>>>>>>                         To reframe it closer to GNAP:
>>>>>>>>>>>                         - AS = AS-RO, that's where you find
>>>>>>>>>>>                         the RO policies. The AS issues
>>>>>>>>>>>                         access tokens to the client.
>>>>>>>>>>>                         - the RO policies could be a)
>>>>>>>>>>>                         defined locally or b) in
>>>>>>>>>>>                         relationship with the RS
>>>>>>>>>>>
>>>>>>>>>>>                         There have been several ideas
>>>>>>>>>>>                         related to the AS-RS relationship b:
>>>>>>>>>>>                         b1) the RS issues capabilities
>>>>>>>>>>>                         (which can be further attenuated by
>>>>>>>>>>>                         the RO)
>>>>>>>>>>>                         b2) Adrian also discussed a DID
>>>>>>>>>>>                         based solution
>>>>>>>>>>>                         b3) there was also an alternative
>>>>>>>>>>>                         ACL proposal from Denis (+ preflight)
>>>>>>>>>>>
>