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

[Stephen Moore <[e-mail]>]

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