Re: [GNAP] Relationship between Authentication and Authorization ?

Adrian Gropper <> Mon, 29 March 2021 12:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76F793A10CA for <>; Mon, 29 Mar 2021 05:49:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pn2nENxid24a for <>; Mon, 29 Mar 2021 05:49:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F68A3A10C3 for <>; Mon, 29 Mar 2021 05:49:04 -0700 (PDT)
Received: by with SMTP id v23so3902780uaq.13 for <>; Mon, 29 Mar 2021 05:49:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sgHqgUCgMvtyY75qQZHRDP91OUFtCwwWzHjZJrUbEQc=; b=ltAWxfDTkx+NPoOPyBZlH6dav1FYez7idDZbBlV9eByHV9zcOLMVIUpqBosVtL3Ye2 QIFMgHH+mdaALWoLtBkcID05VGaTj0aRkFHUkVuP9KYJzI745N9gQTXKnua+vJt0PHmh XhD/tZOddyWp9EkppnTjp69qX9GVK5poFDZvXleWdy5Kh7y9y3kMNAMq/v9MHVGoIBuR TkyI++zmllL40y7R2B6qSTtmS9aGEeakD6BmZBseMjaawc3sZyBTj2z3H0JDFYuDMtCk 0Cz2lhj8CDSWCsMgucdbzV68bbZloWFZ5DPvRTV3zWinm0Yw/PTv2B0dwBu+eyyZ12Qq kE+A==
X-Gm-Message-State: AOAM5322u0YIbSoia5hROR8+7K0oDRblYnToP8+bqxuQKL/aKCUs2NLf 5v1n2vQyDqa6VW/2LFxDKEQsPYX5Cs8VBKdzncY=
X-Google-Smtp-Source: ABdhPJy77JVtU0eqhHaqMQA/aoOtxIejhx1N2i8WuXgmdNpO/wMiiq1eWXTAZuUDiMg2Ek/Sadr+KW6nEZmm+pDXABg=
X-Received: by 2002:ab0:30a3:: with SMTP id b3mr12841575uam.0.1617022142809; Mon, 29 Mar 2021 05:49:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Adrian Gropper <>
Date: Mon, 29 Mar 2021 08:48:50 -0400
Message-ID: <>
To: Denis <>
Cc: Justin Richer <>,
Content-Type: multipart/alternative; boundary="0000000000006a8bed05beac4edc"
Archived-At: <>
Subject: Re: [GNAP] Relationship between Authentication and Authorization ?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Mar 2021 12:49:11 -0000

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

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?


On Mon, Mar 29, 2021 at 6:39 AM Denis <> 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 <> 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 <> 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 <>
> 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 <> 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 <>
>> 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 <> wrote:
>>> Justin Richer <> 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,
>>>  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 <> 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 <> 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 <> 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 <>
>>>>> 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)