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

From: Adrian Gropper <[email-masked]>
Date: Wed, 17 Mar 2021 00:30:10 -0400

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

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 17 Mar 2021 05:47:52 +0100

Not sure about partners and spouses, but I concur with the rest :-))

Le mer. 17 mars 2021 à 05:30, Adrian Gropper <[email-masked]> a
écrit :

> 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
> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 17 Mar 2021 10:55:14 -0400

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 <[email-masked]> wrote:
> 
> 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
> [email-masked]

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 17 Mar 2021 12:21:28 -0400

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.

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.

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.

Adrian

On Wed, Mar 17, 2021 at 10:55 AM Justin Richer <[email-masked]> 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
>
> > 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.
> >
> > Our success, from a human-centered perspective, will come indirectly as
> a result of the GNAP Authorization Server. The user agents and service

---

From: Justin Richer <[email-masked]>
Date: Wed, 17 Mar 2021 13:03:48 -0400

> On Mar 17, 2021, at 12:21 PM, Adrian Gropper <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> > On Mar 17, 2021, at 12:30 AM, Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 17 Mar 2021 16:42:23 -0400

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 <[email-masked]> wrote:

> 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.
>
> 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.
>
>
> 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
>
>
>
>
>
>
>
>> if what they carry is an “AS” in the GNAP sense or not. >From their
>> > 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.
>> >
>> > 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
>> > [email-masked]

---

From: Alan Karp <[email-masked]>
Date: Thu, 18 Mar 2021 14:02:37 -0700

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 <[email-masked]>
wrote:

> 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.
>
>> 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
>>> > Our success, from a human-centered perspective, will come indirectly
>>> as a result of the GNAP Authorization Server. The user agents and service