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

[Fabien Imbault <[e-mail]>]

Hi Adrian,

I'm really not sure I understand here.

I get the idea of putting a policy engine in front of your services to
implement ZTA. But I'm not sure I get this way of framing things. It blurs
functional roles and actual services, and most importantly if everything
gets its own AS, it also gets by transitivity its RO'/RQ' (and then its
AS-RO' etc) and so the complexity becomes staggering.
Why do we need that?

Fabien

Le ven. 19 mars 2021 à 00:55, Adrian Gropper <[e-mail]> a
écrit :

> +1 This aligns with my healthcare use-case to the extent that Justin can
> transfer the capability granted by that QR code to Adrian who happens to be
> nearby Steve's house.
>
> I've tried to capture some of this in my comment to #145
> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-802388458
>
> - Adrian
>
> On Thu, Mar 18, 2021 at 2:39 PM Justin Richer <[e-mail]> wrote:
>
>> Right, and in the GNAP model this becomes something my client instance
>> presents to the AS when I show up. The AS can validate my presentation of
>> this item and give my client instance a token to call Steve’s RS. Or if you
>> wanted to get super fancy Steve’s AS could even challenge my client
>> instance and get a cryptographic response to prove I have the thing Steve
>> had me scan. But in both cases it’s part of things that the AS collects in
>> order to create the access token.
>>
>>  — Justin
>>
>> On Mar 18, 2021, at 2:26 PM, Stephen Moore <[e-mail]> wrote:
>>
>> That in my mind works out great... Say I'm logged into my home hub/AS.
>> Justin is over and agrees to cat sit, I pull up my client app, and generate
>> a QR code that has maybe The AS URI, the HomeHub API URL, and the 'special
>> token to present to AS for a real token'. Justin scans that QR code with
>> his home controller app, and BAM, he's onboarded as a guest without even
>> logging into my AS or me dealing with his Auth provider.
>> -steve
>>
>> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer <[e-mail]> wrote:
>>
>>> I think Steve’s use case gives an interesting example of something that
>>> I believe Adrian’s been talking about as well — delegating to another
>>> person.
>>>
>>> We traditionally think of delegation at the AS to mean “a different user
>>> account logs in to the AS”, and it’s important to know that this does in
>>> fact work. But this could just as easily be “Steve sends his friend an
>>> artifact to present to the AS to get access”. This isn’t Steve (or Steve’s
>>> client software) getting and sending an access token, this is sending some
>>> other set of rights credential to his friend, or his friend’s software. So
>>> then Steve’s AS can have policy that says “when I see this rights
>>> credential, give an access token for the following attenuated things,
>>> because Steve said so”. The AS doesn’t even ever need to know who Steve’s
>>> friend is!
>>>
>>> And importantly here, we don’t expect Steve’s friend to bring their own
>>> AS to the party. Steve’s RS has no reason to trust his friend’s AS, let
>>> alone his friend’s client. But Steve’s AS is in a position to know more
>>> about the rights policies that Steve wants to apply, and so it can use
>>> other technologies like VC’s, DIDs, OIDC, or any number of other things to
>>> let things go through. This pattern is exactly why I think we need to think
>>> of this in terms of what’s currently called “interaction” at the AS. It’s
>>> not really just about how the end-user interacts, it’s about how the AS
>>> gathers all the consent and authorization information. I plan to rewrite
>>> section 4 to that effect.
>>>
>>>  — Justin
>>>
>>> On Mar 18, 2021, at 1:58 PM, Stephen Moore <[e-mail]> wrote:
>>>
>>> I'm having some concerns with the way you're flipping the trust here
>>> Denis. You seem to indicate that the user has trust in the RS and the
>>> Client and has to gain the trust of the AS. I feel like the least
>>> trustworthy portion of the architecture is the client, because that seems
>>> like it is the most interchangeable component.
>>>  Let me explain by way of a use case I have in mind.
>>> Let's say I have a smart home. I have devices and data storage and rule
>>> engines that are parts of sensors and hubs I buy for the house. I have a
>>> trust in those devices, because it's hardware, if the company is leaking
>>> data at the hardware level there isn't much I can do other than buy
>>> different sensors.
>>> In this case, the primary home hub, which is under control of the
>>> homeowner, would also be the AS, as well as a policy agent.  Authentication
>>> in the example is outsourced to whatever auth providers you want. I set up
>>> my home using a google account, a friend is staying and wants access and
>>> uses FB for auth... whatever.
>>> The part that I have little control over is the client my friend uses on
>>> his phone. Or if I change the client on the tablet in the kitchen to try
>>> out something new. These pieces might be single page web apps, they might
>>> be downloaded apps, etc. I do not want them having any additional
>>> information than is necessary. If I give my friend permission to unlock the
>>> door, and control the lights because they are feeding my cats while I'm
>>> away, the client doesn't need to know anything beyond, I see this home
>>> controller, and I have access to these lights and that door lock.
>>>
>>> In your scenarios, the client is spy by design, and if it is a web app,
>>> I don't trust them to not grab my user email address from the AS and put it
>>> on a mailing list it sells to some sketchy company, when the only other
>>> component that needs that information is the RS.
>>>
>>> -steve
>>>
>>> On Thu, Mar 18, 2021 at 1:21 PM Denis <[e-mail]> wrote:
>>>
>>>> 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]> wrote:
>>>>
>>>>> On Mar 18, 2021, at 11:30 AM, Alan Karp <[e-mail]> wrote:
>>>>>
>>>>>
>>>>> Justin Richer <[e-mail]> wrote:
>>>>>
>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp <[e-mail]> wrote:
>>>>>>
>>>>>>
>>>>>> Adrian Gropper <[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]> wrote:
>>>>>
>>>>>> On Mar 18, 2021, at 12:08 AM, Alan Karp <[e-mail]> wrote:
>>>>>>
>>>>>>
>>>>>> Adrian Gropper <[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]> 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]> 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]> 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]> 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]> 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]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Mar 17, 2021, at 4:55 PM, Adrian Gropper <
>>>>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <
>>>>>>>>>>>> [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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> TXAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>> --
>>> TXAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>
>>>
>> --
>> TXAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> --
> TXAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>