Re: [GNAP] Relationship between Authentication and Authorization ?

[Denis <[e-mail]>]

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)
>>>>>>>>>>