Re: [GNAP] Alice a J&J COVID vaccine

[Adrian Gropper <[e-mail]>]

Here's an example:
https://www.governor.ny.gov/news/governor-cuomo-announces-pilot-program-testing-excelsior-pass-madison-square-garden-and

Bob is manning the gate at Madison Square Garden.

Adrian

On Mon, Mar 29, 2021 at 1:19 PM Denis <[e-mail]> wrote:

> 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]> 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]> 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]> 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]> 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]>
>>> 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]> 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]>
>>>> 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]> wrote:
>>>>
>>>>> Justin Richer <[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.  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]> 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]> 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]>
>>>>>> 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]> 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)
>>>>>>>
>>>>>>>
>>
>