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

[Fabien Imbault <[e-mail]>]

Oh I thought capchas were mostly a way to train your AI for free ;-)

Joke aside, I support Justin's view of what goes into core versus what the
kind of modularity we might bring in addition to that.

Fabien

On Fri, Mar 19, 2021 at 6:32 PM Justin Richer <[e-mail]> wrote:

> The only way for the RS operator could introduce a captcha, within the
> definitions of the GNAP protocol, is through an AS. Or more properly,
> through this yes-unnamed aspect of “interacting with the RO” that the AS is
> in charge of coordinating the results of. The RS is not an end-user-facing
> service, it is an API, software meant to be called by other software. The
> defined way for the “RS” to interact with a person, issue tokens, or
> anything of the sort is through an AS.
>
> In OAuth 1, the AS and RS were just called the “authorization server” or
> even just “server", and it seems like a lot of the discussion on this
> thread is collapsing that same set of roles back but instead calling it the
> “RS”. I think this is problematic both in terms of the flexibility of the
> protocol and also in terms of clarity in what we’re describing and
> discussing.
>
>  — Justin
>
> On Mar 19, 2021, at 1:26 PM, Adrian Gropper <[e-mail]>
> wrote:
>
> I agree. The problem is that powerful RS operators introduce things like
> Capchas that hassle the RO. Sometimes this is justified but often it
> reflects an inadequate protocol.
>
> Adrian
>
> On Fri, Mar 19, 2021 at 1:22 PM Justin Richer <[e-mail]> wrote:
>
>> There’s an important difference here:
>>
>> The AS is software. Always. It plays a specific role within the protocol.
>>
>> The RO could be a person. It could be an agency. It could be a policy.
>> They don’t take part in the protocol directly but are involved in decisions
>> made in the course of the protocol.
>>
>> These are two very, very different things, and they can’t be conflated.
>>
>> I like the idea of talking in terms of relationships, such as AS-RS (a
>> protocol relationship) and AS-RO (a trust relationship).
>>
>>  — Justin
>>
>> On Mar 19, 2021, at 12:37 PM, Adrian Gropper <[e-mail]>
>> wrote:
>>
>> It might be a good idea to keep the RS to AS relationship out of the GNAP
>> spec but I’m having a hard time analyzing it in the abstract.
>>
>> My starting perspective is that the RS should not know or care whether it
>> is dealing with the AS or the RO. This is super important because it gives
>> the RO unlimited delegation power.
>>
>> Cases where the RO wants to give the RS a separate endpoint or other
>> identity should be allowed by GNAP but might be out of band. This is the
>> HIPAA API Task Force use case that I have referenced in another thread. The
>> issue here is that the RS has the option of reaching out to the RO and
>> requesting confirmation.
>>
>> Adrian
>>
>> On Fri, Mar 19, 2021 at 11:37 AM Justin Richer <[e-mail]> wrote:
>>
>>> My proposal is that the client instance shouldn’t care what’s in the
>>> token, what format it is, etc.
>>>
>>> The RS can care and there should be choices that include random, sealed,
>>> and even plainly signed tokens. That choice is part of the relationship
>>> between the RS and AS, which the core GNAP protocol doesn’t specify.
>>>
>>> This is why I propose that we extract what’s now section 10 in the draft
>>> and put it into a new document that can more directly discuss that
>>> relationship. These different relationships should be modular.
>>>
>>>  — Justin
>>>
>>> On Mar 19, 2021, at 11:13 AM, Alejandro Iacobelli <
>>> [e-mail]> wrote:
>>>
>>> Agree! So what are you saying the proposal should be? Random or sealed
>>> tokens?
>>>
>>> El El vie, 19 mar. 2021 a la(s) 10:04, Justin Richer <[e-mail]>
>>> escribió:
>>>
>>>> One of the best ways to protect information in the token is to not put
>>>> it in the token in the first place. This is why a some highly-sensitive
>>>> application profiles and deployments us randomized values as tokens. The RS
>>>> has a way to dereference it, which is important.
>>>>
>>>> For downstream delegation, like one micro service calling another,
>>>> we’re no longer talking about the client knowing the access token, we’re
>>>> talking about an RS at the first step. This is where non-opaque, or
>>>> encrypted, or other kinds of recoverable data structures come into play
>>>> more directly.
>>>>
>>>> To Adrian’s point, sharing the QR code should be up to the AS’s policy.
>>>> If Steve gives me a bearer artifact that isn’t attached to anything that
>>>> identifies me, then it’s easy for me to share because the artifact is the
>>>> identity and proof all in one. The strawman description below sounds like
>>>> that. But it’s important in this design that the AS can also require me to
>>>> log in with a specific account, plus present a token, plus type in a secret
>>>> code, plus present a hardware key that completes a circuit in the right way
>>>> (seems like something Steve would build, tbh), etc. But all of these aren’t
>>>> a client talking to a resource, they’re the end-user  presenting things to
>>>> the AS so that the AS can make a policy decision to issue a token and allow
>>>> access.
>>>>
>>>>  — Justin
>>>>
>>>> On Mar 18, 2021, at 8:23 PM, Alejandro Iacobelli <
>>>> [e-mail]> wrote:
>>>>
>>>> The decision about "opaque" vs "sealed but recoverable" or "signed"
>>>> access_token goes way back on the stateless protocols session management.
>>>>
>>>> In my opinion, the software design principle that we must apply here is
>>>> the "need to know" principle. This means, the less information an attacker
>>>> could get, the better. One thing that JWS explse is all the context
>>>> information about a token, so an attacker can get lots of information just
>>>> with a look.
>>>>
>>>> The next discussion will be what ways of generating opaque tokens are
>>>> there and which must we choose (Encrypted vs CSPRNG based).
>>>>
>>>> On Thu, 18 Mar 2021 at 21:17, Fabien Imbault <[e-mail]>
>>>> wrote:
>>>>
>>>>> 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
>>>>>>
>>>>> --
>>>>> TXAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>>
>>>>
>>>> --
>>>> You know nothing Jon Snow!
>>>>
>>>>
>>>> --
>>> You know nothing Jon Snow!
>>>
>>>
>>>
>>
>