Re: [GNAP] GNAP from a human-centered perspective

[Alan Karp <[e-mail]>]

Let's be clear about the trust relationships.  The RS has one with its AS,
call it AS-RS; the RO has one with its AS, call it AS-RO.  I think what
Adrian is saying is clear if we keep that distinction in mind.

--------------
Alan Karp


On Wed, Mar 17, 2021 at 1:42 PM Adrian Gropper <[e-mail]>
wrote:

> Hi Justin,
>
> I just reviewed our charter and I see no clear mandate for an AS-first or
> RS-first presumption.
>
> From my human-centered, subject-empowering perspective, I want to make
> sure that I am not forced into an RS-first authorization model. This means
> that I want control over discovery of an RS that has a relationship with
> me. If I don't trust the RS, and I can't choose an alternative, I will use
> a pseudonym or lie about my identity before interacting with that RS.
>
> If an RS does not allow me to control my AS, then they are forcing me to
> send requesting parties to an actor that I do not want to share request
> data and metadata with. I will then control or hire my own AS and make that
> discoverable to requesting parties I care about. My AS will determine which
> clients get information about the existence of an RS that does not respect
> my choice of AS. If I can, (remember that the RS holds all the cards) I
> will move my information to another RS that respects my AS choice as soon
> as possible and then I will have the power to decide whether to make that
> RS discoverable, or not.
>
> SImply put, I care about where requests are presented and I want GNAP to
> call that the AS. How the client gets to the AS, through out-of band
> discovery or by visiting an RS-first (UMA-style), may not be that relevant
> to the core protocol.
>
> Adrian
>
> On Wed, Mar 17, 2021 at 1:03 PM Justin Richer <[e-mail]> wrote:
>
>>
>>
>> On Mar 17, 2021, at 12:21 PM, Adrian Gropper <[e-mail]>
>> wrote:
>>
>> I think Justin and I are starting from the same assumption that "the RS
>> holds all the cards" but then reaching different conclusions about the GNAP
>> AS.
>>
>> The RS can decide what scopes to honor, can ignore tokens, can choose
>> their jurisdiction and policies, and can often deny service to subjects on
>> a whim. Giving the RS any additional power or coerced trust (e.g.
>> shrink-wrap licenses) over the subject should be avoided by design.
>>
>> One thing the RS controls is the ability to issue a capability to the
>> subject at some point prior to there being any GNAP AS involved. The
>> subject can keep this capability in their client (e.g. a wallet) or can
>> send that capability to a GNAP AS that they choose.
>>
>>
>> I don’t believe this is in scope for GNAP. The abstraction layer offered
>> by the protocol is such that the only communication between the client
>> instance and RS is via an access token issued by an AS. This AS is
>> reachable by the client and trusted by the RS.
>>
>> Fundamentally, what you are describing is function of the AS, at least as
>> far as the GNAP protocol itself is concerned. Remember, this isn’t about
>> deployment, it’s about the roles and responsibilities of the different
>> items involved.
>>
>>
>> Instead of issuing a capability, the RS can also choose to accept a
>> user-controlled AS. They can do that, for example, by storing a (DID)
>> service endpoint to a GNAP AS. The RS could force the subject (as
>> controller) to choose from a list of certified ASs or they could ask the AS
>> to present a certificate from a trusted issuer. This last RS-controlled
>> option is seen in US HIPAA law but it has provisions for the data subject
>> to insist on acceptance of a subject-issued certificate as part of the
>> protocol. The UDAP group is active in profiling the format of these
>> certificates to be used on top of OAuth.
>>
>>
>> I think that all of these things are functions of the AS, not the RS.
>> With many AS deployments in OAuth today, the user can present themselves to
>> the AS using a choice of federated logins. So in GNAP the user’s agent can
>> present a certificate from a trusted issuer. This is not something an AS
>> presents to an RS, it’s something that a different component presents to
>> the AS.
>>
>> The result of this is an access token that the RS will accept. The AS and
>> RS are in the same trust boundary, the crossing of that boundary happens
>> inbound to the AS. This is fundamentally the change in language that I have
>> been trying to push here. While the RS could accept an arbitrary AS, I
>> think it’s both more useful and more realistic for the AS to accept a
>> variety of proofs, claims, certifications, etc from the RO and/or user at
>> runtime in order to make its token.
>>
>>
>> Finally, GNAP should not presume that the AS is either carried by a
>> subject or online. A subject can have the option to choose an unreliable or
>> part-time AS.
>>
>>
>> I disagree with this statement. GNAP is a protocol and is based on HTTP.
>> From a technical level, we have to assume that it is reachable by the
>> client instance at the start of the process. But if we stop trying to put
>> the AS into a place where it doesn’t function well, we can start to talk
>> about the unreliable and part-time authorization-and-consent component
>> (agent, wallet, whatever) that can feed into the AS when available. This
>> leads to a much more robust protocol structure.
>>
>>  — Justin
>>
>> Adrian
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Mar 17, 2021 at 10:55 AM Justin Richer <[e-mail]> wrote:
>>
>>> I think this is a fairly reasonable way to look at things, but the
>>> sticking point for me is the implication of how the AS “brings together”
>>> the items. It could be read to mean that the end-user’s policies all live
>>> on the AS. If the end-user needs to own or control the AS in order for this
>>> to work, I don’t think that pattern has any legs in reality as it requires
>>> an RS to accept access tokens from an unknown source. This means the RS
>>> then needs to understand a LOT more about the access token than it would
>>> otherwise be able to.
>>>
>>> Instead, I would encourage us to think of “brings together” in the sense
>>> that the AS can take as input a number of different things, including
>>> things that the user controls and things the RO controls. This is where I
>>> think we can draw the line around the AS in a way that will let it function
>>> in this human-facing world.
>>>
>>> Because you’re absolutely right that the end user shouldn’t know or care
>>> if what they carry is an “AS” in the GNAP sense or not. From their
>>> perspective, they need to present something to a service to get something
>>> done. In the OAuth world this is “log in to our web server”. In the GNAP
>>> world we can have this include a wider variety of things they can present
>>> to the AS, including VCs and DIDs and a bunch of other things.
>>>
>>>  — Justin
>>>
>>> > On Mar 17, 2021, at 12:30 AM, Adrian Gropper <[e-mail]>
>>> wrote:
>>> >
>>> > I truly appreciate the diligence of our editors and contributors.
>>> >
>>> > Without intruding on the technical discussions, I hope this thread can
>>> be an opportunity for us to step out of our comfort zone and look around.
>>> >
>>> > As a human data subject, I am cognizant and in control of only two
>>> kinds of actors, user agents and services. The user agents are almost
>>> exclusively a handful of web browsers, email clients, and apps duplicated
>>> and sometimes synchronizing across two to four phones and computers. The
>>> services (that I expect have visibility into my persona) are in a dozen
>>> categories from banking and ISPs that I expect to be acting as fiduciaries
>>> to platforms, social networks and other data brokers with their own agenda.
>>> At this altitude, GNAP, DIDs, and ASs are as invisible as MAC addresses and
>>> routers.
>>> >
>>> > Our success, from a human-centered perspective, will come indirectly
>>> as a result of the GNAP Authorization Server. The user agents and service
>>> providers I see (and sometimes choose) will support GNAP along with OAuth
>>> and FIDO and Apple Sign-In as protocols. The common thing about these
>>> protocols is that they coexist and overlap in incomprehensible ways made
>>> even more obscure by DIDs, VCs, and self-issued identity providers (SIOP).
>>> As we get to DIDcomm, even I get lost.
>>> >
>>> > My suggestion or proposal to our group is that we respect the human
>>> perspective by doing our best to make the concept of an authorization
>>> server relevant even if it remains hidden from view behind protocols like
>>> GNAP and OAuth and data models like DID and VC. In doing this we would
>>> recognize that a human's agent would likely support GNAP AS as well as
>>> incumbent attribute management protocols. As a human, I just want my online
>>> agent to work across as many user-agents and services as possible. As with
>>> life partners or spouses, having more than one intelligent semi-autonomous
>>> agent is not typically a benefit.
>>> >
>>> > My concrete suggestion is that GNAP define the AS as the entity or
>>> actor that brings together the subject's policies, the capabilities granted
>>> by services, and requests and serves up authorizations to the requesting
>>> party.
>>> >
>>> > Adrian
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > TXAuth mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>
>>