[GNAP] Should access tokens be opaque or not for the clients ?

[Denis <[e-mail]>]

I have changed the title of this thread, since the original topic has 
been closed.

Justin, you are raising the following question:

    The question I have is — why does the client need to know what’s in
    the token?
    Not if they could possibly know, but why would we expect a client to
    know and manage the contents of the token?

The answer is quite simple: so that the end-user may have confidence 
into the architecture.
The seventh of the eleven privacy principles from ISO 29100 (page 14) is:

    *7. Openness, transparency and notice *

If the access token is considered as a black box for the end-user, it 
cannot be confident about the content of the access token.
Such access token may disclose some private information without the 
consent of the end-user. If the access token that it has obtained
does not match with what has been requested, the client will first not 
forward the access token to the RS and then will complain about the AS.

Denis


> Hi Justin,
>
> "The access token is fundamentally a conversational artifact between 
> the AS and the RS which the client is the carrier of."
> That's right, and a good opportunity to distinguish between the need 
> for token inspection (i.e. a runtime verification, wherever that may be)
> and the need to negotiate the token format (a discovery). That last 
> part could very well be an extension, as a way to open up the ecosystem
> beyond JWTs (which are fine, but come with their own limitations).
>
> Fabien
>
> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On Mar 18, 2021, at 11:30 AM, Alan Karp <[e-mail]
>     <mailto:[e-mail]>> wrote:
>>
>>     Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         On Mar 18, 2021, at 12:08 AM, Alan Karp <[e-mail]
>>         <mailto:[e-mail]>> wrote:
>>>
>>>         Adrian Gropper <[e-mail]
>>>         <mailto:[e-mail]>> wrote:
>>>
>>>
>>>             Is there an AS involved in the delegation? How and where
>>>             in the lifecycle of the protected resource?
>>>
>>>
>>>         If tokens are certificates, the AS need not be involved in
>>>         subsequent delegations.  The AS must be involved if the
>>>         tokens are opaque.
>>
>>         Tokens are opaque to the client instance. They are not opaque
>>         to the AS. They might be opaque to the RS, but that depends
>>         on the kind of relationship the RS and AS have. GNAP should
>>         allow different options here as there are different use cases
>>         for that.
>>
>>
>>     Tokens are not opaque to the client in SPKI, zcap-ld, Orie's
>>     implementation with VCs, or our Zebra Copy work.  Why must they
>>     be in GNAP?
>
>     The existence of the AS is exactly the reason for this. The AS is
>     the role that “knowledge about the token contents” has been
>     outsourced to in the GNAP model (which is based on the OAuth model).
>
>     It brings significant simplicity for the client developer. The
>     question I have is — why does the client need to know what’s in
>     the token? Not if they could possibly know, but why would we
>     expect a client to know and manage the contents of the token?
>
>     The access token is fundamentally a conversational artifact
>     between the AS and the RS which the client is the carrier of. The
>     client is not the audience of the token, nor the creator of the
>     token, nor even the manager of the token and the rights it
>     represents. The client as a simple carrier is a powerful model
>     that allows the security layer to get out of the way of the actual
>     application logic that developers want to do.
>
>      — Justin
>
>>
>>     --------------
>>     Alan Karp
>>
>>
>>     On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         On Mar 18, 2021, at 12:08 AM, Alan Karp <[e-mail]
>>         <mailto:[e-mail]>> wrote:
>>>
>>>         Adrian Gropper <[e-mail]
>>>         <mailto:[e-mail]>> wrote:
>>>
>>>
>>>             Is there an AS involved in the delegation? How and where
>>>             in the lifecycle of the protected resource?
>>>
>>>
>>>         If tokens are certificates, the AS need not be involved in
>>>         subsequent delegations.  The AS must be involved if the
>>>         tokens are opaque.
>>
>>         Tokens are opaque to the client instance. They are not opaque
>>         to the AS. They might be opaque to the RS, but that depends
>>         on the kind of relationship the RS and AS have. GNAP should
>>         allow different options here as there are different use cases
>>         for that.
>>
>>         It would probably be worthwhile to separate the portions of
>>         the spec that talk about the RS-AS relationship into its own
>>         standalone document. A similar approach was taken in UMA2 and
>>         it was helpful. (Though admittedly, as with anything, there
>>         are missteps there that we can hopefully learn from.)
>>
>>          — Justin
>>
>>>
>>>         --------------
>>>         Alan Karp
>>>
>>>
>>>         On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper
>>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>             Sure!
>>>
>>>             Is there an AS involved in the delegation? How and where
>>>             in the lifecycle of the protected resource?
>>>
>>>             Also your use of "the client" seems to imply that either
>>>             there is only one client or the client doesn't matter.
>>>             Which is it?
>>>
>>>             Adrian
>>>
>>>             On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault
>>>             <[e-mail]
>>>             <mailto:[e-mail]>> wrote:
>>>
>>>                 Thanks for that.
>>>
>>>                 Trying to reframe it:
>>>                 GNAP is defined as a delegation protocol so the main
>>>                 intent is related to a delegate of the RO (i.e. the
>>>                 end user) that wishes to access the RO's protected
>>>                 resources, through the client.
>>>
>>>                 Fabien
>>>
>>>                 Le jeu. 18 mars 2021 à 04:29, Adrian Gropper
>>>                 <[e-mail]
>>>                 <mailto:[e-mail]>> a écrit :
>>>
>>>                     At various points in the lifecycle of the
>>>                     protected resource the client at the resource
>>>                     server (RS) might be:
>>>
>>>                       * The RO (subject) user agent trading payment
>>>                         for a service promise
>>>                       * The RO user agent using the promise to
>>>                         access the protected resource
>>>                       * A delegate of the RO user agent using a
>>>                         different client
>>>
>>>                     What's vague is where the GNAP AS enters the
>>>                     picture as described above. How would you
>>>                     describe it?
>>>
>>>                     Adrian
>>>
>>>
>>>                     On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault
>>>                     <[e-mail]
>>>                     <mailto:[e-mail]>> wrote:
>>>
>>>                         Hi Adrian
>>>
>>>                         I'm still confused why you're saying the
>>>                         terminology is vague.
>>>                         I get the "power" neutrality is not to your
>>>                         liking, but RQ / user agent is no better in
>>>                         my view.
>>>
>>>                         Can you elaborate?
>>>
>>>                         Fabien
>>>
>>>                         Le jeu. 18 mars 2021 à 00:18, Adrian Gropper
>>>                         <[e-mail]
>>>                         <mailto:[e-mail]>> a écrit :
>>>
>>>                             I'm sure you're right. Our vague
>>>                             terminology around client and end-user
>>>                             leads to my confusion. If GNAP is
>>>                             primarily about delegation then, of
>>>                             course, we should avoid any incentives
>>>                             to impersonate or we're wasting our
>>>                             time. This is partly why I'm trying to
>>>                             study up on capabilities and asking for
>>>                             expert advice from folks like Alan Karp
>>>                             and Mark Miller (cc'd)
>>>
>>>                             As best I can understand it, the RS has
>>>                             only two choices, it can:
>>>
>>>                               * store an attribute of the RO a [DID,
>>>                                 email address, GNAP AS URL], or
>>>                               * hand the RO a capability as a
>>>                                 sort-of promise and avoid making any
>>>                                 entries in an ACL or equivalent.
>>>
>>>                             When a token comes back to the RS, it
>>>                             will either be:
>>>
>>>                               * validated according to something
>>>                                 associated with the stored RO
>>>                                 attribute, or
>>>                               * signed by the RS itself.
>>>
>>>                             Either way, trust in the client seems moot.
>>>
>>>                             Adrian
>>>
>>>
>>>
>>>                             On Wed, Mar 17, 2021 at 5:29 PM Justin
>>>                             Richer <[e-mail]
>>>                             <mailto:[e-mail]>> wrote:
>>>
>>>                                 On Mar 17, 2021, at 4:55 PM, Adrian
>>>                                 Gropper <[e-mail]
>>>                                 <mailto:[e-mail]>> wrote:
>>>>
>>>>                                 On Wed, Mar 17, 2021 at 4:23 PM
>>>>                                 Tobias Looker
>>>>                                 <[e-mail]
>>>>                                 <mailto:[e-mail]>>
>>>>                                 wrote:
>>>>
>>>>                                     <snip>
>>>>                                     > A client might not have a DID
>>>>                                     but it could have a VC as a
>>>>                                     certificate of authenticity
>>>>                                     linked to some audit mechanism.
>>>>
>>>>                                     To me a VC would come under the
>>>>                                     assertions umbrella (that is to
>>>>                                     say a VC could be one type of
>>>>                                     valid assertion). The client
>>>>                                     may possess or been presented
>>>>                                     with a VC that it could include
>>>>                                     in its request to the AS as a
>>>>                                     way to identify the subject and
>>>>                                     perhaps prove authentication
>>>>                                     and authorization.
>>>>
>>>>
>>>>                                 I do not assume that the client
>>>>                                 that interacts with the AS to make
>>>>                                 a request and receive a token is
>>>>                                 the same as the client that will
>>>>                                 present the token to the RS. In the
>>>>                                 US HIPAA use-case, for example, the
>>>>                                 root of trust is a contract between
>>>>                                 the patient-subject and the
>>>>                                 doctor-requesting party but the
>>>>                                 doctor workflow is expected to
>>>>                                 delegate the token to some other
>>>>                                 end-user that may be using a
>>>>                                 totally different client such as an
>>>>                                 EHR.
>>>>
>>>
>>>                                 If the client that gets the token is
>>>                                 not same as the client that uses the
>>>                                 token, that is a violation of core
>>>                                 security principles as it allows for
>>>                                 (and really designs for)
>>>                                 impersonation by client software. I
>>>                                 would have no reason to trust client
>>>                                 software that would hand its
>>>                                 credentials over to another piece of
>>>                                 software, and in fact I shouldn’t
>>>                                 trust it.
>>>
>>>                                 I think you may be conflating
>>>                                 several different kinds of parties
>>>                                 under the “client” umbrella here,
>>>                                 though. It’s entirely possible that
>>>                                 one client might call an RS that in
>>>                                 turn acts as a client for something
>>>                                 else down stream. But each of those
>>>                                 hops is different from the last.
>>>
>>>                                  — Justin
>>>
>>
>
>