Re: [GNAP] DID as sub_id or assertion?

[Adrian Gropper <[e-mail]>]

That's the vagueness we're talking about. For me, the RS holds all the
cards and can choose whether to hold them or pass them to some other actor.
"Same trust boundary" just reinforces that mental model for me, it's a
technicality that splits one actor into two pieces. If the RS does this it
should be completely invisible to GNAP and I would call the whole thing RS
anyway.

The reason I advocate for GNAP in the SSI workgroups is exactly because SSI
does not depend on "trust boundary" - which to me is another name for
"federation".

So, on the protocols side, I propose, in both the SSI and GNAP groups, that
the AS be defined as the actor that has policies, requests, and
capabilities in order to emit tokens. If there's a reason to treat this
actor as a trust boundary around an RO + the user-agent or the RO + an AS,
then I'm happy to state that explicitly.

Adrian

On Wed, Mar 17, 2021 at 7:36 PM Justin Richer <[e-mail]> wrote:

> I still think the RS doesn’t do these things, the AS does. The AS is the
> component of the “API Provider’ (in your use case model) that handles the
> authorizations. The RS just fulfills them. They are part of the same trust
> boundary.
>
>  — Justin
>
> On Mar 17, 2021, at 7:18 PM, Adrian Gropper <[e-mail]>
> wrote:
>
> 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
>>
>>
>