Subject: [GNAP] GNAP Architecture and the role of the AS

From: Justin Richer <[email-masked]>
Date: Fri, 12 Mar 2021 12:07:41 -0500

As discussed at the IETF meeting, the editors proposed that one of our next big topic areas was going to be the nature of the AS role within the GNAP protocol, especially how it relates to the device-driven use cases that have been brought up. Apologies in advance for the long post, but there are a lot of parts to this discussion that I’m hoping we can kick off here.

My core proposal is that we see the AS as the component that has the following properties:
 - receives delegation requests from the client instance for access to an RS via access tokens, and for access to subject information returned directly to the client instance
 - collects consent and authorization from the RO for the delegation
 - issues access tokens that its downstream RS’s can interpret (and validate/accept)
 - issues subject information asserted by the AS 

This framing of the parties is really important in making a consistent understanding of how the protocol works, and a consistent understanding is vital if we’re going to function as a working group in both discussing the problem space and executing the solution space. For a historical example, a naive approach to adding identity on top of a protocol like OAuth 2 (or GNAP) is to declare that the resource server is the thing the user is logging in to. This seems reasonable at first (and some people tried doing this) but it violates all kinds of trust boundaries and puts new expectations on the different parties that do not make sense. It stops looking anything like OAuth very quickly and turns into another protocol. If instead we say the user is logging in to the client, things suddenly make a lot more sense and we can do a lot more with it. (See this blog post from 2013 for one take on that discussion: https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/ <https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/>)

I think we’ve got a similar situation here when we start to talk about the user bringing their own AS with them. I think this is a reasonable-seeming assumption but it’s based on a false premise that the RO has to log into the AS to approve the request, and the AS has full control and view over everything in the network. While OAuth doesn’t require this, it’s largely assumed that’s how it works. After all, all of the early OAuth deployments worked exactly this way: the user logs in and clicks the “OK” button. However, cloud deployments have shown us that it’s perfectly reasonable for an OAuth AS to take in its consent and user information from an external trusted source, and so this model is not even accurate in OAuth.

In short, I think we can do a better job here of defining things in terms that both accept the reality we face and enable new ideas in ways that make sense. It’s my stance that the user shouldn’t need to bring the AS with them in order to have the kind of input and control of the system that people are asking for. Instead, the AS should be able to take inputs from things that the user controls in order for the AS to do its job.

People have discussed privacy concerns with the AS knowing “too much”, but in many of those discussions the knowledge is simply pushed to the RS instead. What I’m observing here is really just pushing portions of the AS role into the “RS” deployment. This doesn’t make it less of an “AS” role, it’s just being fulfilled closely to where the RS role is fulfilled. As such, my proposal is really not that different in practice, but the labels are different and better aligned with the capabilities of the protocol. 

We’ve previously talked about separating the user-facing portions of the AS into another component, and I think now might be the time to do that. This is a very flammable strawman proposal, but what if we had the AS defined, as above, and the “consent and authorization” gathering portion is augmented by another named component. Here let’s call it an Interaction Component. This can take several forms based on the kind of interaction mode in use:

 - Hosted at a URL the user is redirected to; it can then make the user log in, consent, and whatever else they need to do
 - Hosted at a URL the user will load separately and enter in an access code
 - An app on the user’s device that the user interacts with directly and which sends information back to the AS
 - An app reachable by a messaging endpoint that the AS sends and receives structured information from
 - The client itself that is given an indication as to what information the AS needs in order to fulfill the request; this could be MFA challenge/response, user credentials, signed claims, etc.

It’s the AS’s job to accept any and all of these that it supports and churn those into an access token. 

The AS itself doesn’t ever need to have the user log in. The AS doesn’t necessarily need to even know who the user is in any way. The AS just needs to know from a trusted source that the request is approved.

From a practical standpoint, I think this will have some small changes in how we talk about the components and how we talk about the interaction phase of the grant negotiation process. Everything I’m laying out here is currently allowed by the spec, but I think we’ve carried through the same assumptions from OAuth 2 about deployment that are both inaccurate and confusing. 

 — Justin

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 12 Mar 2021 18:22:56 +0100

Hi Justin,

Just a quick word to say I very much agree with both the observations and
the framing.

Fabien

On Fri, Mar 12, 2021 at 6:07 PM Justin Richer <[email-masked]> wrote:

> As discussed at the IETF meeting, the editors proposed that one of our
> next big topic areas was going to be the nature of the AS role within the
> GNAP protocol, especially how it relates to the device-driven use cases
> that have been brought up. Apologies in advance for the long post, but
> there are a lot of parts to this discussion that I’m hoping we can kick off
> here.
>
>  - receives delegation requests from the client instance for access to an
> RS via access tokens, and for access to subject information returned
> directly to the client instance
> This framing of the parties is really important in making a consistent
> understanding of how the protocol works, and a consistent understanding is
> vital if we’re going to function as a working group in both discussing the
> problem space and executing the solution space. For a historical example, a
> naive approach to adding identity on top of a protocol like OAuth 2 (or
> GNAP) is to declare that the resource server is the thing the user is
> logging in to. This seems reasonable at first (and some people tried doing
> this) but it violates all kinds of trust boundaries and puts new
> expectations on the different parties that do not make sense. It stops
> looking anything like OAuth very quickly and turns into another protocol.
> If instead we say the user is logging in to the client, things suddenly
> make a lot more sense and we can do a lot more with it. (See this blog post
> from 2013 for one take on that discussion:
> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/)
>
> I think we’ve got a similar situation here when we start to talk about the
> user bringing their own AS with them. I think this is a reasonable-seeming
> assumption but it’s based on a false premise that the RO has to log into
> the AS to approve the request, and the AS has full control and view over
> everything in the network. While OAuth doesn’t require this, it’s largely
> assumed that’s how it works. After all, all of the early OAuth deployments
> worked exactly this way: the user logs in and clicks the “OK” button.
> However, cloud deployments have shown us that it’s perfectly reasonable for
> an OAuth AS to take in its consent and user information from an external
> trusted source, and so this model is not even accurate in OAuth.
>
> In short, I think we can do a better job here of defining things in terms
> that both accept the reality we face and enable new ideas in ways that make
> sense. It’s my stance that the user shouldn’t need to bring the AS with
> them in order to have the kind of input and control of the system that
> people are asking for. Instead, the AS should be able to take inputs from
> things that the user controls in order for the AS to do its job.
>
> People have discussed privacy concerns with the AS knowing “too much”, but
> in many of those discussions the knowledge is simply pushed to the RS
> instead. What I’m observing here is really just pushing portions of the AS
> role into the “RS” deployment. This doesn’t make it less of an “AS” role,
> it’s just being fulfilled closely to where the RS role is fulfilled. As
> such, my proposal is really not that different in practice, but the labels
> are different and better aligned with the capabilities of the protocol.
>
> We’ve previously talked about separating the user-facing portions of the
> AS into another component, and I think now might be the time to do that.
> This is a very flammable strawman proposal, but what if we had the AS
> defined, as above, and the “consent and authorization” gathering portion is
> augmented by another named component. Here let’s call it an Interaction
> Component. This can take several forms based on the kind of interaction
> mode in use:
>
>  - Hosted at a URL the user is redirected to; it can then make the user
> log in, consent, and whatever else they need to do
>  - The client itself that is given an indication as to what information
> the AS needs in order to fulfill the request; this could be MFA
> challenge/response, user credentials, signed claims, etc.
>
> The AS itself doesn’t ever need to have the user log in. The AS doesn’t
> necessarily need to even know who the user is in any way. The AS just needs
> to know from a trusted source that the request is approved.
>
> From a practical standpoint, I think this will have some small changes in
> how we talk about the components and how we talk about the interaction
> phase of the grant negotiation process. Everything I’m laying out here is
> currently allowed by the spec, but I think we’ve carried through the same
> assumptions from OAuth 2 about deployment that are both inaccurate and
> confusing.
>
>  — Justin
> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Adrian Gropper <[email-masked]>
Date: Fri, 12 Mar 2021 16:34:04 -0500

Let’s try to map a real-world use-case into the names and roles we are
discussing. The use-case is documented as the API Task Force
Recommendations (2016)
https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-APITFRecommendations.pdf
and I’ve copied below the most relevant section. Bold highlight is in the
original. I’ve added bold italic because it may be important to our
discussion.

<quote>

   -

   ONC should clarify that while API Providers may impose security related
   restrictions on app access (e.g. rate limiting, encryption, and expiration
   of access tokens), it is inappropriate for API providers to set limitations
   on what a patient authorized app can do with data downstream.
   -

      Given the nature of patient access rights, the provider is not in a
      legal position to prevent the registration of apps that would
aggregate or
      share data, for example (though the provider might certainly
decide to warn
      the patient, or endeavor to educate and explain these issue to
the patient,
      as part of the provider hosted app approval workflow).
      -

   ONC should clarify that API providers are not obligated to protect
   patients by identifying "suspicious" apps. API providers may suspend API
   access to an app that has breached the API provider's terms of service ,
   or appears to have been compromised, or if the app poses a threat to the
   provider's own system. However, patients must be able to override this
   suspension (except in the case where an app poses threat to the
   provider's own system or violates allowable terms of service).

</quote>

The key requirements from a patient rights and privacy perspective are:

   1.

   To delegate a scope-limited access capability to anyone anywhere without
   having to explain or justify that to the API Provider.
   2.

   To allow the patient to automate the issue of a scope-limited access
   capability by delegating the authority to process API access requests to
   some agent. The API Provider has no say in who or where this agent is.
   3.

   The automation of the agent is based on policies provided by the
   patient. The agent is able to process access requests from anyone and is
   responsible only to the patient. The agent responds to successful requests
   by issuing a filtered capability to the requesting party.
   4.

   To ensure that the requesting party can delegate the capability using an
   institutional workflow system that they trust and the patient doesn’t know
   or care about. In many cases, the workflow system will pass the capability
   to some other person, who we might call the end user. In other cases, the
   requesting party may forward the capability directly to another person
   using, for example, an email. Either way, the client app used by the
   end-user to access the API is of no concern to the patient or to the
   patient’s agent.
   5.

   To ensure that the API Provider does not censor the client app that
   presents the capability or solicits too much information about the client
   app or the end-user of the client app.
   6.

   If the API Provider decides, for any reason, to be “suspicious” (as
   above) of the access transaction based on the information it has, it should
   be possible for the API Provider to warn the patient and to accept an
   override of the warning by the patient. This effectively means that the
   end-user will provide as much information as they think will be necessary
   in order to either avoid “suspicion” or risk waiting for patient override.
   7.

   The policies by which the patient or the decides to grant a capability
   to the requesting party are never shared outside of the patient-agent trust
   relationship. In other words, neither the patient nor the agent is asked to
   share or explain their reason for an access decision.
   8.

   Access requests to the agent are presumed confidential among the
   patient, the agent, and whatever client the requesting party uses to
   present an access request. The API Provider does not get to see the
   requests and no entity in the GNAP authorization process, other than the
   patient or the agent, gets to correlate across requests by different
   requesting party clients.

Note that I am not saying all 8 requirements are in scope for GNAP but I am
asking for GNAP to allow for this level of privacy on the part of
self-sovereign patients using self-sovereign agents and the self-sovereign
licensed professionals they deal with.

Adrian

On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault <[email-masked]>
wrote:

>> I think we’ve got a similar situation here when we start to talk about
>> the user bringing their own AS with them. I think this is a
>> reasonable-seeming assumption but it’s based on a false premise that the RO
>> has to log into the AS to approve the request, and the AS has full control
>> and view over everything in the network. While OAuth doesn’t require this,
>> it’s largely assumed that’s how it works. After all, all of the early OAuth
>> deployments worked exactly this way: the user logs in and clicks the “OK”
>> button. However, cloud deployments have shown us that it’s perfectly
>> reasonable for an OAuth AS to take in its consent and user information from
>> an external trusted source, and so this model is not even accurate in OAuth.
>>
>> People have discussed privacy concerns with the AS knowing “too much”,
>> but in many of those discussions the knowledge is simply pushed to the RS

---

From: Denis <[email-masked]>
Date: Mon, 15 Mar 2021 10:24:04 +0100

Hi Justin,

My comments are between the lines.

> next big topic areas was going to be the nature of the AS role within 
> the GNAP protocol,
> especially how it relates to the device-driven use cases that have 
> been brought up. Apologies in advance for the long post, but there are 
> a lot of parts
> to this discussion that I’m hoping we can kick off here.

[Comment from Denis] The "device-driven use cases" are not addressed any 
further in this email. IMO, they are only possible if/when a secure element
with some specific security properties is being used by the end-user and 
when the AS is able to verify that it is indeed used by the end-user.
I am not disputing that this would be an interesting case but ,before 
going any further, we would have to modify the terms of our charter.

>  - receives delegation requests from the client instance for access to 
> an RS via access tokens,
>    and for access to subject information returned directly to the 
> client instance
>
[Comment from Denis] The RO on the AS side is an optional component.
>  - issues access tokens that its downstream RS’s can interpret (and 

[Comment from Denis] This sentence must remain true whether or not the 
AS and the RS have established a prior relationship.
When there is no prior relationship between an AS and a RS, the RS must 
be able to disclose to the Client, the access token format(s),
as well as the crypto algorithms, it supports. In the same way, the AS 
must be able to disclose to the Client, the access token format(s),
as well as the crypto algorithms, it supports. If there is no match, it 
is unnecessary to continue the exchanges.

It is important to mention that the access token contains privileges, 
i.e. end-user attributes or/and rights.

  * When end-user attributes are contained into an access token, it is
    possible to implement on the RS side an ABAC or a RBAC or an IBAC.

  * When rights are contained into an access token, it is possible to
    implement on the RS side a capability model.

A major difference between these two models is the point from which the 
access control rules are administered:

  * When end-user attributes are contained into an access token, the
    administration of the access control rules is only done by a
    Resource Owner sitting on the RS side.
  * When rights are contained into an access token, the administration
    of the access control rules is primally done by a Resource Owner
    sitting on the AS side
    but is also controlled by another by a Resource Owner sitting on the
    RS side which establishes the trust conditions.

>  - issues subject information asserted by the AS

[Comment from Denis] Still the same difficulty about the use of the term 
"subject" which remains unsolved, this sentence is ambiguous:
is the "end-user" information placed into an access token ?

> understanding of how the protocol works, and a consistent 
> understanding is vital
> if we’re going to function as a working group in both discussing the 
> problem space and executing the solution space. For a historical example,
> a naive approach to adding identity on top of a protocol like OAuth 2 
> (or GNAP) is to declare that the resource server is the thing the user 
> is logging in to.
> This seems reasonable at first (and some people tried doing this) but 
> it violates all kinds of trust boundaries and puts new expectations on 
> the different parties
> that do not make sense. It stops looking anything like OAuth very 
> quickly and turns into another protocol. If instead we say the user is 
> logging in to the client,
> things suddenly make a lot more sense and we can do a lot more with 
> it. (See this blog post from 2013 for one take on that discussion:
> https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/ 
> <https://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/>)

[Comment from Denis] This link does not work. After 10 minutes of 
search, here is the appropriate link: 
/https://www.cloudidentity.com/blog/?p=251/
to be able to access to this very looooong article (this will take you 
more than 30 minutes to read).

[Comment from Denis] GNAP and OAuth 2.0 are both authorization 
frameworks, i.e. they are NOT authentication protocols.
An authorization may be given to a "calling application", called the 
"client" in our draft.

Before obtaining a response when calling an API, a Resource Server (RS) 
MAY mandate to authenticate the end-user.
In such a case, if no authentication exchange has successfully taken 
place, it will return the error /401 Unauthorized/, which is the HTTP 
status code
for authentication errors: it’s for authentication, not authorization. 
Receiving a 401 response is the server telling you, “you, as an end-user,
aren’t authenticated–either not authenticated at all or authenticated 
incorrectly–but please re-authenticate and try again.”
To help you out, it will always include a /WWW-Authenticate/ header that 
describes how to authenticate.

The long post from 2013 contains one important sentence : " OAuth is 
interested in what takes place AFTER authentication,"
which means that an authentication MAY happen BEFORE OAuth takes 
place.This clearly means that an authentication exchange MAY exist.
Unfortunately this is currently not mentioned in the draft, whereas it 
should be described in the draft.

This raises an interesting question which has been left aside. What is 
the relationship (if any) between the end-user identifier used
for an authentication exchange and a "sub-id" claim or a "sub" claim 
present inside an access token ?

The long post from 2013 contains another important sentence :
"keeping AS and RS under the same roof is baked in OAuth’s common usage, 
if not the spec itself." This is true.

In GNAP, this assumption is no more valid as the ASs and the RSs are not 
necessarily any more "under the same roof".

> reasonable-seeming assumption
> but it’s based on a false premise that the RO has to log into the AS 
> to approve the request, and the AS has full control and view over 
> everything in the network.
> While OAuth doesn’t require this, it’s largely assumed that’s how it 
> works. After all, all of the early OAuth deployments worked exactly 
> this way: the user logs in
> and clicks the “OK” button. However, cloud deployments have shown us 
> that it’s perfectly reasonable for an OAuth AS to take in its consent 
> and user information
> from an external trusted source, and so this model is not even 
> accurate in OAuth.

[Comment from Denis] It is more important to explain first how GNAP will 
work rather than stating what's wrong in OAuth.

> In short, I think we can do a better job here of defining things in 
> terms that both accept the reality we face and enable new ideas in 
> ways that make sense.
> It’s my stance that the user shouldn’t need to bring the AS with them 
> in order to have the kind of input and control of the system that 
> people are asking for.
> Instead, the AS should be able to take inputs from things that the 
> user controls in order for the AS to do its job.
[Comment from Denis] The writer surely understands what this means, but 
not me.
> but in many of those discussions the knowledge is simply pushed to the 
> RS instead.

[Comment from Denis] There is no argument to explain "how the knowledge 
is simply pushed to the RS instead". During the last IETF GNAP meeting,
I presented some slides enumerating various privacy properties while 
comparing access control scheme based on ACLs versus access control 
schemes based
on capabilities (i.e. rights):

1)*Unlinkeability between RS user accounts *: Two RSs should not be able 
to link their user accounts, by using the content of the access tokens 
they receive
     from the same AS or from different ASs.

2) *AS-RS untraceability:* The AS is unable to know for which RS an 
issued access token is targeted.

3)*AS-Client Operation/Method hiding*: The AS is unable to know which 
Operation/Method will be performed by the client on which object of a RS.

4)*AS-Client access time invisibility : *The AS is unable to know 
exactly when an issued access token will be consumed by a RS.

5) *End-user confidence in the system*: The client can verify that the 
access token contains the requested / adequate privileges and,
     if not, it can block the transmission of the access token to the RS.

At the moment, the current draft does not list these privacy properties. 
If it would, it would indicate that the AS is able to know :

  * for which RS an issued access token is targeted,
  * which Operation/Method will be performed by the client on which
    object hosted by the RS,
  * exactly when an issued access token will be consumed by the RS (as
    soon as Token Introspection is supported),

which means that *the AS would be able to act as a **Big Brother*.

In addition if the access tokens are considered to be opaque to the 
clients, the end-user cannot have confidence that the AS discloses only 
the requested privileges
and no more.

*If these properties were advertised to the reader of the draft, which 
end-users would accept to use such a system which is opaque to the 
end-users
and where the AS is able to act as Big Brother ?*

There have been some arguments at the very beginning about the fact that 
the RO and the end-users were both able to have an account on the AS,
because this was implicitly the case with OAuth.

The charter states:

Although the artifacts for this work are not intended or expected to be 
backwards-compatible with OAuth 2.0 or OpenID Connect,
the group will attempt to simplify migrating from OAuth 2.0 and OpenID 
Connect to the new protocol where possible.

This clearly means that GNAP is not intended or expected to be 
backwards-compatible with OAuth 2.0 or OpenID Connect.

Originally, OAuth was invented to deal with the case where the same 
organization was managing the AS and a set of RSs.

What was not explained is that an architecture /_using an AS_ /dealing 
with capabilities (i.e. rights) allows the AS to know/spy every action 
from the users on the RSs.
There may be good business reasons to do so, but if privacy properties 
had been taken into consideration it would have been possible to provide 
the same services
without using any AS.

Since we don't need to achieve a backwards compatibility, I would say 
that it is still possible to use OAuth in the case where the RO = the 
end-user.

It would also say that it would still be possible to define an 
architecture taking into consideration privacy requirements and to 
define an architecture with any AS
to perform operations similar to OAuth. Such an architecture has been 
defined during the last century, more precisely in July 1988 under the 
standard ECMA-131
RDT (Referenced Data Transfer). This standard is still available at: 
/https://www.ecma-international.org/wp-content/uploads/ECMA-131_1st_edition_july_1988.pdf/

> What I’m observing here is really just pushing portions of the AS role 
> into the “RS” deployment. This doesn’t make it less of an “AS” role, 
> it’s just being fulfilled
> closely to where the RS role is fulfilled. As such, my proposal is 
> really not that different in practice, but the labels are different 
> and better aligned with the capabilities
> of the protocol.

[Comment from Denis] Which proposal ?

> We’ve previously talked about separating the user-facing portions of 
> the AS into another component, and I think now might be the time to do 
> that.
> defined, as above, and the “consent and authorization” gathering portion
> is augmented by another named component. Here let’s call it an 
> Interaction Component.

[Comment from Denis] First of all, using the privacy vocabulary, this is 
not “consent and authorization”, but it is "user notice", "user choice" 
and "user consent".

Before making one or more choices, the end-user must be able to be 
informed about the reasons and /or the consequences of each choice.
Then he must be able to make some choice(s) and finally he may indicate 
his consent for these choices.

A key question is: At which moment such "user notice, choice and consent 
happens ? If an end-user has never contacted a RS before,
this happens after a "discovery" flight and BEFORE contacting any AS.

Since, there exist some situations where there is a single AS, some 
people may believe that these choices are the same whether they are made 
immediately
after the first RS call or after the first AS call, and hence that that 
is is possible to use a same building block for both cases. 
Unfortunately this is not the case.

As soon as a RS is trusting more than one AS, the user choice is first 
to select the AS(s) after being informed of which privileges are 
requested/needed
by a RS to respond positively on a method performed on an object.

Furthermore, as soon as an AS has not established a prior relationship 
with the RS, an AS is unable to present any choice to the end-user.

So, /for the time being/, we should not presume that the functions can 
be factored and thus it is important to consider, /for the time being/,
that *there is no such "Interaction Component"*.

> This can take several forms based on the kind of interaction mode in use:
>
>  - Hosted at a URL the user is redirected to; it can then make the 
> user log in, consent, and whatever else they need to do
>  - An app on the user’s device that the user interacts with directly 
> and which sends information back to the AS
>  - The client itself that is given an indication as to what 
> information the AS needs in order to fulfill the request; this could 
> be MFA challenge/response, user credentials, signed claims, etc.
>

[Comment from Denis] No. It is not necessarily the AS's job. The AS job 
is to place into an access token the privileges that have been requested 
by the client.

> The AS itself doesn’t ever need to have the user log in. The AS 
> doesn’t necessarily need to even know who the user is in any way.
> The AS just needs to know from a trusted source that the request is 
> approved.
[Comment from Denis] *No, no and no again for each of these three 
sentences*. It is rather strange to change the model and the (implicit) 
trust relationships at this time.
I fear that we are following a moving target.

When writing the first draft, *the cart has been placed before the 
horse*, which means that the components of the model, their 
relationships and their trust relationships
have not been defined, and that the protocols have been designed without 
a clear model and without explaining their rational.

> From a practical standpoint, I think this will have some small changes 
> in how we talk about the components and how we talk about the 
> interaction phase
> of the grant negotiation process. Everything I’m laying out here is 
> currently allowed by the spec, but I think we’ve carried through the 
> same assumptions from OAuth 2
> about deployment that are both inaccurate and confusing.

[Comment from Denis] The writer surely understands what this means, but 
not me.
Which assumptions from OAuth 2 about deployment are both inaccurate and 
confusing ?

Denis

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 15 Mar 2021 11:29:32 +0100

Hi Adrian,

It's good to check what that means in real use cases indeed.

My view:
Items 1-2-3-7 : seems quite usual. Only in this example, the patient is the
RO and generally delegates its decision to an automated policy engine
(equivalent to seq 1.4.4).
I believe item 4 (delegation, beyond the original token issuance) would be
hard to do using JWT, at least in a generic way.
Items 5 is probably beyond our scope, although Denis expressed the same
requirement related to "solicits too much info" (based on non opaque
tokens, which might not be the general assumption / I personally think
token content should remain opaque to the client, but knowing the type of
the token would be useful).
Item 6 asks for a relationship between RS and RO, which I'm not sure we'd
want to assume for the general case (although it could happen in some
scenarii).
Item 8 is fine in principle, but would require attention to make sure it's
the case in practice. Depending on the sub_ids used (and even if opaque, as
soon as dereferencing is allowed), correlation might be possible.

Does that seem correct?
Fabien

On Fri, Mar 12, 2021 at 10:34 PM Adrian Gropper <[email-masked]>
wrote:

>    ONC should clarify that while API Providers may impose security
>    related restrictions on app access (e.g. rate limiting, encryption, and
>    expiration of access tokens), it is inappropriate for API providers to set
>    limitations on what a patient authorized app can do with data downstream.
>    -
>
>       legal position to prevent the registration of apps that would aggregate or
>       share data, for example (though the provider might certainly decide to warn
>       the patient, or endeavor to educate and explain these issue to the patient,
>    patients by identifying "suspicious" apps. API providers may suspend
>    API access to an app that has breached the API provider's terms of
>    service , or appears to have been compromised, or if the app poses a threat
>    to the provider's own system. However, patients must be able to
>    override this suspension (except in the case where an app poses threat
>    to the provider's own system or violates allowable terms of service).
>
>
>
> </quote>
>
>    To delegate a scope-limited access capability to anyone anywhere
>    without having to explain or justify that to the API Provider.
>    2.
>
>    To ensure that the requesting party can delegate the capability using
>    an institutional workflow system that they trust and the patient doesn’t
>    know or care about. In many cases, the workflow system will pass the
>    capability to some other person, who we might call the end user. In other
>    cases, the requesting party may forward the capability directly to another
>    person using, for example, an email. Either way, the client app used by the
> Note that I am not saying all 8 requirements are in scope for GNAP but I
> am asking for GNAP to allow for this level of privacy on the part of
>>> an RS via access tokens, and for access to subject information returned
>>> terms that both accept the reality we face and enable new ideas in ways
>>> that make sense. It’s my stance that the user shouldn’t need to bring the
>>> AS with them in order to have the kind of input and control of the system
>>> that people are asking for. Instead, the AS should be able to take inputs
>>> from things that the user controls in order for the AS to do its job.
>>>
>>> in how we talk about the components and how we talk about the interaction

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 15 Mar 2021 12:01:33 +0100

Hi Denis,

I don't intend to comment on everything, just my 2 cents (personal view) in
red.

Cheers
Fabien

On Mon, Mar 15, 2021 at 10:24 AM Denis <[email-masked]> wrote:

> GNAP protocol,
> especially how it relates to the device-driven use cases that have been
> brought up. Apologies in advance for the long post, but there are a lot of
> parts
> RS via access tokens,
>    and for access to subject information returned directly to the client
> instance
>
> [Comment from Denis] This sentence must remain true whether or not the AS
> and the RS have established a prior relationship.
> When there is no prior relationship between an AS and a RS, the RS must be
> able to disclose to the Client, the access token format(s),
> as well as the crypto algorithms, it supports. If there is no match, it is
> unnecessary to continue the exchanges.
>
> It is important to mention that the access token contains privileges, i.e.
> end-user attributes or/and rights.
>
>    - When end-user attributes are contained into an access token, it is
> [FIM] not currently covered by GNAP, this could be possible, cf
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/203

>
>    - When rights are contained into an access token, it is possible to
>    - When end-user attributes are contained into an access token, the
>    administration of the access control rules is only done by a Resource Owner
>    sitting on the RS side.
>    - When rights are contained into an access token, the administration
> [FIM] yes, there are good reasons for both, GNAP I believe should be
agnostic, only considering by default the case where the RO is on the AS
side, but still allowing the case when the RO has an account on the RS side

> is the "end-user" information placed into an access token ?
[FIM] in the AS definition, we explain quite clearly that acces token and
subject info are distinct. Justin has submitted a new PR 211 that even
clarifies that further.

> vital
> a naive approach to adding identity on top of a protocol like OAuth 2 (or
> logging in to.
> This seems reasonable at first (and some people tried doing this) but it
> violates all kinds of trust boundaries and puts new expectations on the
> different parties
> that do not make sense. It stops looking anything like OAuth very quickly
> and turns into another protocol. If instead we say the user is logging in
> to the client,
> things suddenly make a lot more sense and we can do a lot more with it.
> (See this blog post from 2013 for one take on that discussion:
> [Comment from Denis] This link does not work. After 10 minutes of search,
> here is the appropriate link: *https://www.cloudidentity.com/blog/?p=251
> <https://www.cloudidentity.com/blog/?p=251>*
> [Comment from Denis] GNAP and OAuth 2.0 are both authorization frameworks,
> i.e. they are NOT authentication protocols.
> place, it will return the error *401 Unauthorized*, which is the HTTP
> status code
> To help you out, it will always include a *WWW-Authenticate* header that
> which means that an authentication MAY happen BEFORE OAuth takes place.  This
> clearly means that an authentication exchange MAY exist.

[FIM] maybe it needs clarification, but the sequence diagrams do mention
AuthN

> This raises an interesting question which has been left aside. What is the
> relationship (if any) between the end-user identifier used

[FIM] already the case in many OAuth2 deployments

> assumption
> but it’s based on a false premise that the RO has to log into the AS to
> approve the request, and the AS has full control and view over everything
> in the network.
> works. After all, all of the early OAuth deployments worked exactly this
> way: the user logs in
> and clicks the “OK” button. However, cloud deployments have shown us that
> it’s perfectly reasonable for an OAuth AS to take in its consent and user
> information
> from an external trusted source, and so this model is not even accurate in
> OAuth.
>
> sense.
> It’s my stance that the user shouldn’t need to bring the AS with them in
> order to have the kind of input and control of the system that people are
> asking for.
> Instead, the AS should be able to take inputs from things that the user
> controls in order for the AS to do its job.
>
> instead.
> [Comment from Denis] There is no argument to explain "how the knowledge is
> simply pushed to the RS instead". During the last IETF GNAP meeting,
> comparing access control scheme based on ACLs versus access control schemes
> based
> 1)* Unlinkeability between RS user accounts *: Two RSs should not be able
> to link their user accounts, by using the content of the access tokens they
> receive
> 3)* AS-Client Operation/Method hiding*: The AS is unable to know which
> 4)* AS-Client access time invisibility : *The AS is unable to know
>    - for which RS an issued access token is targeted,
>    - which Operation/Method will be performed by the client on which
>    object hosted by the RS,
>    - exactly when an issued access token will be consumed by the RS (as
> [FIM] we planned a privacy consideration section (issue 133).

> clients, the end-user cannot have confidence that the AS discloses only the
> requested privileges
> and no more.
>
>
> end-users and where the AS is able to act as Big Brother ?*
>
[FIM] that's a point of view, but one could think otherwise. The proposed
alternative puts a lot of trust on the client, which might be a problem in
practice.

> What was not explained is that an architecture *using an AS *dealing with
> capabilities (i.e. rights) allows the AS to know/spy every action from the
> users on the RSs.
> There may be good business reasons to do so, but if privacy properties had
> been taken into consideration it would have been possible to provide the
> same services
> without using any AS.
>
> Since we don't need to achieve a backwards compatibility, I would say that
> it is still possible to use OAuth in the case where the RO = the end-user.
>
[FIM] there are other major advances in GNAP when RO = end-user

> architecture taking into consideration privacy requirements and to define
> an architecture with any AS
> RDT (Referenced Data Transfer). This standard is still available at: *https://www.ecma-international.org/wp-content/uploads/ECMA-131_1st_edition_july_1988.pdf
> <https://www.ecma-international.org/wp-content/uploads/ECMA-131_1st_edition_july_1988.pdf>*
>
> into the “RS” deployment. This doesn’t make it less of an “AS” role, it’s
> just being fulfilled
> closely to where the RS role is fulfilled. As such, my proposal is really
> not that different in practice, but the labels are different and better
> aligned with the capabilities
> of the protocol.
>
> is augmented by another named component. Here let’s call it an Interaction
> Component.
>
> not “consent and authorization”, but it is "user notice", "user choice" and
> "user consent".
>
[FIM] possibly, but that is an assumption that could be discussed. I've
written a short description of why I think the situation might be more
complex than it seems
https://fimbault.medium.com/consent-is-dead-long-live-consent-2d64a434cdf6

> Since, there exist some situations where there is a single AS, some people
> may believe that these choices are the same whether they are made
> immediately
> after the first RS call or after the first AS call, and hence that that is
> is possible to use a same building block for both cases. Unfortunately this
> is not the case.
>
> As soon as a RS is trusting more than one AS, the user choice is first to
> select the AS(s) after being informed of which privileges are
> requested/needed
[FIM] an option preflight with the RS would enable this. Again issue 203.

> So, *for the time being*, we should not presume that the functions can be
> factored and thus it is important to consider, *for the time being*,
[FIM] At any one point in time, there is only one AS (cf discussion in
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/215, with
comments from Justin, Adrian and myself). So I don't think we want to
aggregate several requests to different ASs into one anyways.

> [Comment from Denis] No. It is not necessarily the AS's job. The AS job is
> to place into an access token the privileges that have been requested by
> the client.
>
> necessarily need to even know who the user is in any way.
> When writing the first draft, *the cart has been placed before the horse*,
> which means that the components of the model, their relationships and their
> trust relationships
> have not been defined, and that the protocols have been designed without a
> clear model and without explaining their rational.
>
[FIM] I don't think that's the case, we're starting from what people use
today (OAuth2 and OpenID), and change what seems necessary, instead of
changing completely the model. My point of view is that a big part -
probably not everything - of what you propose (which is interesting) can be
achieved based on what GNAP proposes (+ some adjustments that could lead to
PRs).

> phase
> assumptions from OAuth 2

---

From: Adrian Gropper <[email-masked]>
Date: Mon, 15 Mar 2021 07:42:49 -0400

inline...

On Mon, Mar 15, 2021 at 6:29 AM Fabien Imbault <[email-masked]>
wrote:

> Items 1-2-3-7 : seems quite usual. Only in this example, the patient is
> the RO and generally delegates its decision to an automated policy engine
[AG] Yes.  This ability to automate under consent is foundational to any
large-scale information exchange or data brokerage use-case.

> hard to do using JWT, at least in a generic way.
[AG] Whatever GNAP decides for token formats, at least one of them MUST
support delegation otherwise, the RO is unable to hold a
requester responsible. Put another way, a zero-trust architecture SHOULD
hold an individual responsible. In an SSI model, it's the individual that
controls their credentials and a non-repudiable signature and it's this
individual that is present at the time the request is issued so that
individual can use their wallet and be subject to non-repudiation. What
happens afterward is the responsibility of this requester.

[AG] The end-user framing we are currently working with has blurred this
distinction between the entity trusted by the RO and the entity that
operates the client at the RS. This, IMHO, needs to be fixed ASAP. lest we
break compatibility with zero-trust architecture for no good reason.

> the token would be useful).
[AG] I'll take the "probably" for now. It's in everyone's interest for GNAP
to build on data minimization as a principle. Nobody can keep the RS from
asking for too much because, by definition, the RS holds all the cards. If
an RS asks for too much then the request will pass the AS but fail at the
RS. In cases where the RO has a choice of RS, the RS will lose business and
that should keep them from asking too much. In cases where the RO is at the
mercy of the RS, the only thing GNAP might be able to do is provide useful
error messages to the various parties. In other words, GNAP needs to
consider which errors and warnings are in scope.

> want to assume for the general case (although it could happen in some
[AG] See my perspective on Item 5 just above. It's up to GNAP to decide
which errors and warnings need to be handled in scope. Beyond that, RSs and
ROs will have a relationship whether GNAP likes it or not.

> soon as dereferencing is allowed), correlation might be possible.
[AG] In the SSI world we talk in terms of mediators as a separate entity
that is trusted by the RO to limit correlation. GNAP should be agnostic to
whether a mediator is involved. Ideally, GNAP would note that there are two
separate correlation threats. Correlation by the requesters and correlation
by the RSs. Note that I don't worry about correlation by the AS because, by
design, I want my agent to know everything it can and to minimize what all
other participants, except the RO and RO user agent know.

[AG] A mediator allows the RO to use a pseudonym to their AS endpoint as
long as the RO registers the pseudonym with the mediator first. Keeping the
RS (and AS) from correlating separate end-users requires the end-user (and
maybe the requester) to use a mediator themselves. I don't see any of this
being a problem for GNAP but it might be helpful to have an informative
mention of mediators in a privacy considerations section.

Adrian

>> and I’ve copied below the most relevant section. Bold highlight is in
>> the original. I’ve added bold italic because it may be important to our
>> discussion.
>>
>>
>> <quote>
>>
>>    -
>>
>>       Given the nature of patient access rights, the provider is not in
>>       a legal position to prevent the registration of apps that would aggregate
>>       or share data, for example (though the provider might certainly decide to
>>       warn the patient, or endeavor to educate and explain these issue to the
>>       patient, as part of the provider hosted app approval workflow).
>>       -
>>
>>    override this suspension (except in the case where an app poses
>>    threat to the provider's own system or violates allowable terms of service).
>>
>>
>>
>> </quote>
>>
>>    The policies by which the patient or the decides to grant a
>>    capability to the requesting party are never shared outside of the
>>    patient-agent trust relationship. In other words, neither the patient nor
>>    the agent is asked to share or explain their reason for an access decision.
>>    8.
>>
>>> Just a quick word to say I very much agree with both the observations
>>> and the framing.
>>>
>>> Fabien
>>>
>>>> that. This is a very flammable strawman proposal, but what if we had the AS

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 15 Mar 2021 12:56:18 +0100

Thanks Adrian.

Useful comments, thanks.

"The end-user framing we are currently working with has blurred this
distinction between the entity trusted by the RO and the entity that
operates the client at the RS. This, IMHO, needs to be fixed ASAP." What do
you suggest?

Thxs
Fabien

On Mon, Mar 15, 2021 at 12:43 PM Adrian Gropper <[email-masked]>
wrote:

> [AG] I'll take the "probably" for now. It's in everyone's interest for
> GNAP to build on data minimization as a principle. Nobody can keep the RS
> from asking for too much because, by definition, the RS holds all the
> cards. If an RS asks for too much then the request will pass the AS but
> fail at the RS. In cases where the RO has a choice of RS, the RS will lose
> business and that should keep them from asking too much. In cases where the
> RO is at the mercy of the RS, the only thing GNAP might be able to do is
> provide useful error messages to the various parties. In other words, GNAP
> needs to consider which errors and warnings are in scope.
>
>
>> Item 8 is fine in principle, but would require attention to make sure
>> it's the case in practice. Depending on the sub_ids used (and even if
>> opaque, as soon as dereferencing is allowed), correlation might be possible.
>>
>>>    To ensure that the requesting party can delegate the capability
>>>    using an institutional workflow system that they trust and the patient
>>>    doesn’t know or care about. In many cases, the workflow system will pass
>>>    the capability to some other person, who we might call the end user. In
>>>    other cases, the requesting party may forward the capability directly to
>>>    another person using, for example, an email. Either way, the client app
>>>    used by the end-user to access the API is of no concern to the patient or
>>>    to the patient’s agent.
>>>    5.
>>>
>>>>> )
>>>>> information the AS needs in order to fulfill the request; this could be MFA
>>>>> doesn’t necessarily need to even know who the user is in any way. The AS
>>>>> just needs to know from a trusted source that the request is approved.
>>>>>

---

From: Adrian Gropper <[email-masked]>
Date: Mon, 15 Mar 2021 09:49:54 -0400

Thanks for asking, Fabien (and Justin).

I never had a problem with RQ as the entity that brings claims, scope, and
purpose to an AS (that is holding a capability and policies) and gets a
token.

I understand the attraction of dealing with end-user in cases where the
end-user can be the RO but that changes the focus of attention and leads to
a problem in the HIPAA use-case and other use-cases that try to priorotize
human rights and zero-trust architecture
https://docs.google.com/presentation/d/1ksKal62ZiApX09Nejm4RSqHzHJbgwpu_l2Ho64_ePKU/edit#slide=id.p
.

A bit philosophically but helpful as a privacy and community advocate, I
have found it useful to analyze protocols in terms of power instead of
trust and have learned a lot from that invited expert role in W3C SSI WGs
as well as capabilities experts like Alan Karp and Mark Miller. Trust is
often forced on the individual by powerful governing interests or just the
fact that a sick person is in pain, anxious, overwhelmed, even scared.
Presuming trust is not much different from coercion as an exercise of
power.

SSI data models have leveled the power playing field but GNA protocol is
where the rubber meets the road in terms of human rights and security
architecture.

Adrian

On Mon, Mar 15, 2021 at 7:56 AM Fabien Imbault <[email-masked]>
wrote:

>> I believe item 4 (delegation, beyond the original token issuance) would
>>> be hard to do using JWT, at least in a generic way.
>>>
>>> Item 6 asks for a relationship between RS and RO, which I'm not sure
>>> we'd want to assume for the general case (although it could happen in some
>>> scenarii).
>>>
>>>> the original. I’ve added bold italic because it may be important to
>>>> our discussion.
>>>>
>>>>
>>>> <quote>
>>>>
>>>>    -
>>>>
>>>>       Given the nature of patient access rights, the provider is not
>>>>       in a legal position to prevent the registration of apps that would
>>>>       aggregate or share data, for example (though the provider might certainly
>>>>       decide to warn the patient, or endeavor to educate and explain these issue
>>>>       to the patient, as part of the provider hosted app approval workflow).
>>>>       -
>>>>
>>>>    patients by identifying "suspicious" apps. API providers may
>>>>    suspend API access to an app that has breached the API provider's
>>>>    terms of service , or appears to have been compromised, or if the app poses
>>>>    a threat to the provider's own system. However, patients must be
>>>>    able to override this suspension (except in the case where an app
>>>>    poses threat to the provider's own system or violates allowable terms of
>>>>    service).
>>>>
>>>>
>>>>
>>>> </quote>
>>>>
>>>>    To allow the patient to automate the issue of a scope-limited
>>>>    access capability by delegating the authority to process API access
>>>>    requests to some agent. The API Provider has no say in who or where this
>>>>    agent is.
>>>>    3.
>>>>
>>>> Note that I am not saying all 8 requirements are in scope for GNAP but
>>>> I am asking for GNAP to allow for this level of privacy on the part of
>>>> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault <
>>>> [email-masked]> wrote:
>>>>
>>>>> Hi Justin,
>>>>>
>>>>>> As discussed at the IETF meeting, the editors proposed that one of
>>>>>> our next big topic areas was going to be the nature of the AS role within
>>>>>> the GNAP protocol, especially how it relates to the device-driven use cases
>>>>>>  - receives delegation requests from the client instance for access
>>>>>> to an RS via access tokens, and for access to subject information returned
>>>>>> This framing of the parties is really important in making a
>>>>>> consistent understanding of how the protocol works, and a consistent
>>>>>> understanding is vital if we’re going to function as a working group in
>>>>>> both discussing the problem space and executing the solution space. For a
>>>>>> historical example, a naive approach to adding identity on top of a
>>>>>> protocol like OAuth 2 (or GNAP) is to declare that the resource server is
>>>>>> the thing the user is logging in to. This seems reasonable at first (and
>>>>>> some people tried doing this) but it violates all kinds of trust boundaries
>>>>>> and puts new expectations on the different parties that do not make sense.
>>>>>> It stops looking anything like OAuth very quickly and turns into another
>>>>>> protocol. If instead we say the user is logging in to the client, things
>>>>>> suddenly make a lot more sense and we can do a lot more with it. (See this
>>>>>> blog post from 2013 for one take on that discussion:
>>>>>> I think we’ve got a similar situation here when we start to talk
>>>>>> about the user bringing their own AS with them. I think this is a
>>>>>> People have discussed privacy concerns with the AS knowing “too
>>>>>> much”, but in many of those discussions the knowledge is simply pushed to
>>>>>> the RS instead. What I’m observing here is really just pushing portions of
>>>>>> the AS role into the “RS” deployment. This doesn’t make it less of an “AS”
>>>>>> role, it’s just being fulfilled closely to where the RS role is fulfilled.
>>>>>> As such, my proposal is really not that different in practice, but the
>>>>>> labels are different and better aligned with the capabilities of the
>>>>>> protocol.
>>>>>>
>>>>>> From a practical standpoint, I think this will have some small
>>>>>> changes in how we talk about the components and how we talk about the
>>>>>> interaction phase of the grant negotiation process. Everything I’m laying
>>>>>> out here is currently allowed by the spec, but I think we’ve carried
>>>>>> through the same assumptions from OAuth 2 about deployment that are both
>>>>>> inaccurate and confusing.
>>>>>>
>>>>>>  — Justin
>>>>>> --
>>>>>> TXAuth mailing list
>>>>>> [email-masked]

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 15 Mar 2021 15:12:55 +0100

Thanks Adrian.

I'm not very familiar with HIPAA (being based in Europe) but I don't see
"end-user" as being in opposition with ZTA. To me (s)he's just the one
using the client software, in such a way that the AS indeed needs to
establish sufficient confidence in who that is to make him/her get access.
(S)he could either be the RO or not.

But it's true we never define its position of power to the RO. Not sure how
we could include it.

Fabien

On Mon, Mar 15, 2021 at 2:50 PM Adrian Gropper <[email-masked]>
wrote:

>>>>>    To ensure that the API Provider does not censor the client app
>>>>>    that presents the capability or solicits too much information about the
>>>>>    client app or the end-user of the client app.
>>>>>    6.
>>>>>
>>>>>    If the API Provider decides, for any reason, to be “suspicious”
>>>>>    (as above) of the access transaction based on the information it has, it
>>>>>    should be possible for the API Provider to warn the patient and to accept
>>>>>    an override of the warning by the patient. This effectively means that the

---

From: Adrian Gropper <[email-masked]>
Date: Mon, 15 Mar 2021 10:57:22 -0400

No worries, GDPR is a lot like HIPAA. It's built around the separation of
concerns between "controller" and "processor". Take that separation of
concerns to mean the controller and processor have to be separate legal
entities when designing GNAP. (OAuth obscures that distinction.) The
controller receives requests and holds privacy policies but might never see
the data itself in most cases. The processor has only security to worry
about. If it can avoid making any identity decisions by using capabilities
then it saves a lot of risk and cost. If the data being processed is
encrypted, as in W3C Confidential Storage WG where I'm trying to insist on
GNAP as the protocol, then the processor (a W3C / DIF Encrypted Data Vault)
has even fewer legal responsibilities and lower compliance costs.

I'm not against keeping the end-user actor as someone in control of their
Self Sovereign Identity. The hard part is that SSI does not consider
delegation. The policies are assumed to be in the end-user's head, not
their wallet. That assumption is what GNAP now has to deal with because
we've been delegated the delegation work.

To consider power as part of our GNAP definitions language, we need to
acknowledge the role of fiduciaires as accountable delegates and the audit
protocols that keep them honest. Start by watching
https://www.netflix.com/title/81350429

GNAP may be able to avoid introducing the role of notary before we're
through but someone will need to introduce auditability of what the AS and
RS do if they're fiduciary controllers and processors respectively. That's
what's keeping me up at night.

Adrian

On Mon, Mar 15, 2021 at 10:13 AM Fabien Imbault <[email-masked]>
wrote:

> But it's true we never define its position of power to the RO. Not sure
> how we could include it.
>
> Fabien
>
>
>> I never had a problem with RQ as the entity that brings claims, scope,
>> and purpose to an AS (that is holding a capability and policies) and gets a
>> token.
>>
>>>> On Mon, Mar 15, 2021 at 6:29 AM Fabien Imbault <
>>>>> Items 1-2-3-7 : seems quite usual. Only in this example, the patient
>>>>> is the RO and generally delegates its decision to an automated policy
>>>>> engine (equivalent to seq 1.4.4).
>>>>>
>>>> [AG] Yes.  This ability to automate under consent is foundational to
>>>> any large-scale information exchange or data brokerage use-case.
>>>>
>>>> [AG] The end-user framing we are currently working with has blurred
>>>> this distinction between the entity trusted by the RO and the entity that
>>>>> Items 5 is probably beyond our scope, although Denis expressed the
>>>>> same requirement related to "solicits too much info" (based on non opaque
>>>> [AG] In the SSI world we talk in terms of mediators as a separate
>>>> entity that is trusted by the RO to limit correlation. GNAP should be
>>>> agnostic to whether a mediator is involved. Ideally, GNAP would note that
>>>> there are two separate correlation threats. Correlation by the requesters
>>>> and correlation by the RSs. Note that I don't worry about correlation by
>>>> the AS because, by design, I want my agent to know everything it can and to
>>>> minimize what all other participants, except the RO and RO user agent know.
>>>>
>>>> [AG] A mediator allows the RO to use a pseudonym to their AS endpoint
>>>> as long as the RO registers the pseudonym with the mediator first. Keeping
>>>> the RS (and AS) from correlating separate end-users requires the end-user
>>>> (and maybe the requester) to use a mediator themselves. I don't see any of
>>>> this being a problem for GNAP but it might be helpful to have an
>>>> informative mention of mediators in a privacy considerations section.
>>>>
>>>> Adrian
>>>>
>>>>>
>>>>> Does that seem correct?
>>>>> Fabien
>>>>>
>>>>> On Fri, Mar 12, 2021 at 10:34 PM Adrian Gropper <
>>>>> [email-masked]> wrote:
>>>>>
>>>>>> Let’s try to map a real-world use-case into the names and roles we
>>>>>> are discussing. The use-case is documented as the API Task Force
>>>>>> Recommendations (2016)
>>>>>> and I’ve copied below the most relevant section. Bold highlight is
>>>>>> in the original. I’ve added bold italic because it may be important
>>>>>> to our discussion.
>>>>>>
>>>>>>
>>>>>> <quote>
>>>>>>
>>>>>>    -
>>>>>>
>>>>>>    ONC should clarify that API providers are not obligated to
>>>>>>    protect patients by identifying "suspicious" apps. API providers may
>>>>>> Note that I am not saying all 8 requirements are in scope for GNAP
>>>>>> but I am asking for GNAP to allow for this level of privacy on the part of
>>>>>>> Just a quick word to say I very much agree with both the
>>>>>>> observations and the framing.
>>>>>>>
>>>>>>> Fabien
>>>>>>>
>>>>>>>> We’ve previously talked about separating the user-facing portions
>>>>>>>> of the AS into another component, and I think now might be the time to do
>>>>>>>>  - An app on the user’s device that the user interacts with
>>>>>>>> directly and which sends information back to the AS

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 15 Mar 2021 16:02:49 +0100

Yes, a good movie to watch ;-) - they deserved their Golden Globe.
Auditability is certainly of major importance, I agree we should open an
issue on that topic.

Fabien

On Mon, Mar 15, 2021 at 3:57 PM Adrian Gropper <[email-masked]>
wrote:

>>>>> I believe item 4 (delegation, beyond the original token issuance)
>>>>>> would be hard to do using JWT, at least in a generic way.
>>>>>>
>>>>> [AG] Whatever GNAP decides for token formats, at least one of them
>>>>> MUST support delegation otherwise, the RO is unable to hold a
>>>>> [AG] See my perspective on Item 5 just above. It's up to GNAP to
>>>>> decide which errors and warnings need to be handled in scope. Beyond that,
>>>>> RSs and ROs will have a relationship whether GNAP likes it or not.
>>>>>
>>>>>
>>>>>>>       Given the nature of patient access rights, the provider is
>>>>>>>       not in a legal position to prevent the registration of apps that would
>>>>>>>    suspend API access to an app that has breached the API
>>>>>>>    provider's terms of service , or appears to have been compromised, or if
>>>>>>>    the app poses a threat to the provider's own system. However, patients
>>>>>>>    must be able to override this suspension (except in the case
>>>>>>>    where an app poses threat to the provider's own system or violates
>>>>>>>    allowable terms of service).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> </quote>
>>>>>>>
>>>>>>>>>  - receives delegation requests from the client instance for
>>>>>>>>> access to an RS via access tokens, and for access to subject information
>>>>>>>>> returned directly to the client instance
>>>>>>>>> In short, I think we can do a better job here of defining things
>>>>>>>>> in terms that both accept the reality we face and enable new ideas in ways

---

From: Justin Richer <[email-masked]>
Date: Mon, 15 Mar 2021 15:42:07 -0400

Hi Adrian, thanks so much for writing up this use case. I’ve included some thoughts below into how different aspects of GNAP might map to these requirements. I don’t think mapping any human system to any technology is clean and dry, but for what it’s worth I do see a lot of alignment.

> On Mar 12, 2021, at 4:34 PM, Adrian Gropper <[email-masked]> wrote:
> 
> Let’s try to map a real-world use-case into the names and roles we are discussing. The use-case is documented as the API Task Force Recommendations (2016) https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-APITFRecommendations.pdf <https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-APITFRecommendations.pdf> and I’ve copied below the most relevant section. Bold highlight is in the original. I’ve added bold italic because it may be important to our discussion. 
> 
> <quote>
> ONC should clarify that while API Providers may impose security related restrictions on app access (e.g. rate limiting, encryption, and expiration of access tokens), it is inappropriate for API providers to set limitations on what a patient authorized app can do with data downstream.
> Given the nature of patient access rights, the provider is not in a legal position to prevent the registration of apps that would aggregate or share data, for example (though the provider might certainly decide to warn the patient, or endeavor to educate and explain these issue to the patient, as part of the provider hosted app approval workflow).
> ONC should clarify that API providers are not obligated to protect patients by identifying "suspicious" apps. API providers may suspend API access to an app that has breached the API provider's terms of service , or appears to have been compromised, or if the app poses a threat to the provider's own system. However, patients must be able to override this suspension (except in the case where an app poses threat to the provider's own system or violates allowable terms of service).
> 
> </quote>
> 
> To delegate a scope-limited access capability to anyone anywhere without having to explain or justify that to the API Provider.

This will always be susceptible to the level of granularity that the API Provider allows the API to be accessed in. 

Standard APIs (which would result in standard “type” values in the “access” request array) can help with this by defining sufficient levels of detail. But ultimately, the user could never ask for a scope that the API Provider isn’t willing to express.

> To allow the patient to automate the issue of a scope-limited access capability by delegating the authority to process API access requests to some agent. The API Provider has no say in who or where this agent is.

This is where I think this discussion really should go. On the surface, this seems to lead to the “bring your own AS” model. I am contending that it’s more powerful to have an AS (still under the API Provider’s control) that allows the user to provide additional inputs during the protocol process. As an industry, we can standardize and innovate a lot of those inputs, but ultimately GNAP should be able to just connect those endpoints to each other (in my opinion). One of the common inputs is going to remain “get someone to log in at this webpage at the AS and click a button”, but I’m convinced there will be others.

> The automation of the agent is based on policies provided by the patient. The agent is able to process access requests from anyone and is responsible only to the patient. The agent responds to successful requests by issuing a filtered capability to the requesting party.

In this case, shouldn’t it be that the agent is separated from the AS? Since the patient is going to have data protected by different API Provders, to me it stands to reason that they’d want the same agent acting for them on different systems. Each of those systems would still have its own AS, but the AS would be facilitated by the user’s input.

Now this is NOT saying that the user would have their own AS to delegate something to the downstream AS. Or even saying that the user would have some kind of XACML policy server. I’m not sure exactly how the bits on the wire would work but a strawman would look something like:

User -> Client: go access my medical data
Client -> RS: hey I want to access this medical data
RS -> Client: sure go talk to this AS
Client -> Agent: I need to make a request for data, how can I get the AS in touch with you?
Agent -> Client: tell them to use [some kind of magic]
Client -> AS: hey I want to access this medical data; I can get the user to interact with you or I can put you in touch with their policy agent
AS -> Client: OK I’ll talk to the policy agent
AS -> Agent: I have a request for data, I need you to prove that you have the right to release this data
Agent -> User: It looks like Client is asking for stuff at RS through AS, that cool?
Agent -> AS: OK, here you go [more magic]
AS -> Client: ok, here’s an access token that’s good for accessing that AS
Client -> RS: hey, I want to access this medical data and here’s an access token for it

> To ensure that the requesting party can delegate the capability using an institutional workflow system that they trust and the patient doesn’t know or care about. In many cases, the workflow system will pass the capability to some other person, who we might call the end user. In other cases, the requesting party may forward the capability directly to another person using, for example, an email. Either way, the client app used by the end-user to access the API is of no concern to the patient or to the patient’s agent. 

To facilitate this, the “agent” above can be augmented with other capabilities based on what’s being asked for. Adding a line to the flow above:

User -> Client: go access my medical data
Client -> RS: hey I want to access this medical data
RS -> Client: sure go talk to this AS
Client -> Agent: I need to make a request for data, how can I get the AS in touch with you?
Agent -> Client: tell them to use [some kind of magic]
Client -> AS: hey I want to access this medical data; I can get the user to interact with you or I can put you in touch with their policy agent
AS -> Client: OK I’ll talk to the policy agent
AS -> Agent: I have a request for data, I need you to prove that you have the right to release this data
Agent -> User: It looks like Client is asking for stuff at RS through AS, that cool?
Agent -> AS: OK, here you go [more magic]
AS -> RO: It looks like someone's asking for an RS you have the approval for, that cool?
AS -> Client: ok, here’s an access token that’s good for accessing that AS
Client -> RS: hey, I want to access this medical data and here’s an access token for it

In other words, when the AS gets the request, it can and should take in inputs from multiple different dimensions in order to make the authorization decision and encode that into the access token.

> To ensure that the API Provider does not censor the client app that presents the capability or solicits too much information about the client app or the end-user of the client app. 

This is one of the reasons that the AS-based model is really important in GNAP — the API Provider's RS only needs to know “is this token good for what’s being asked”. 

> If the API Provider decides, for any reason, to be “suspicious” (as above) of the access transaction based on the information it has, it should be possible for the API Provider to warn the patient and to accept an override of the warning by the patient. This effectively means that the end-user will provide as much information as they think will be necessary in order to either avoid “suspicion” or risk waiting for patient override.

If the AS can reach out to the patient through notice and consent, they can be brought into the process in an interactive way above. This assumes the AS has a way of connecting that, but we should assume the AS can provide this kind of notice and consent to parties that aren’t directly involved in the protocol flow in the same way the end user is.

> The policies by which the patient or the decides to grant a capability to the requesting party are never shared outside of the patient-agent trust relationship. In other words, neither the patient nor the agent is asked to share or explain their reason for an access decision. 

In the above pattern, the AS and agent would need a way to communicate this with each other. I think the details of this are outside the scope of GNAP but it could take the form of a query/response fulfillment language. VC’s address part of this, but I think there will need to be other aspects brought to bear here. I think you could have a privacy-preserving protocol that would layer into GNAP here, but I don’t know for sure what that would look like.

> Access requests to the agent are presumed confidential among the patient, the agent, and whatever client the requesting party uses to present an access request. The API Provider does not get to see the requests and no entity in the GNAP authorization process, other than the patient or the agent, gets to correlate across requests by different requesting party clients.

This would be a different kind of model, where the client would act as some kind of proxy in the process. Something more like:

User -> Client: go access my medical data
Client -> RS: hey I want to access this medical data
RS -> Client: sure go talk to this AS
Client -> Agent: I need to make a request for data, how can I get the AS in touch with you?
Agent -> Client: tell them to use [some kind of magic]
Client -> AS: hey I want to access this medical data; I can get the user to interact with you or I can forward your request details to the policy agent
AS -> Client: OK go talk to the policy agent, ask for these kinds of things
Client -> Agent: I have a request for data, at this AS, I need you to prove that you have the right to release this data
Agent -> User: It looks like Client is asking for stuff at RS through AS, that cool?
Agent -> Client: OK, here you go [more magic]
Client -> AS: Here’s the result of that policy thing you asked for [more magic]
AS -> Client: ok, here’s an access token that’s good for accessing that AS
Client -> RS: hey, I want to access this medical data and here’s an access token for it

> 
> Note that I am not saying all 8 requirements are in scope for GNAP but I am asking for GNAP to allow for this level of privacy on the part of self-sovereign patients using self-sovereign agents and the self-sovereign licensed professionals they deal with.

For me the important part is that GNAP allow these kinds of trust connections. Even if GNAP isn’t solving every piece of this equation, it can at least clearly state “there’s a function here that needs to / is able to solve this thing” and build the important parts around it.

 - Justin

> 
> Adrian
> 
> 
> On Fri, Mar 12, 2021 at 2:50 PM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Justin, 
> 
> Just a quick word to say I very much agree with both the observations and the framing.
> 
> Fabien
> 
> On Fri, Mar 12, 2021 at 6:07 PM Justin Richer <[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>
> -- 
> TXAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 16 Mar 2021 02:45:29 +0100

Hi Justin

A few questions :
- we're covering the use case "get my medical data", how does that change
if that's someone else's data?
- what happens if the agent can't guarantee availability?

Fabien

Le lun. 15 mars 2021 à 20:42, Justin Richer <[email-masked]> a écrit :

> Hi Adrian, thanks so much for writing up this use case. I’ve included some
> thoughts below into how different aspects of GNAP might map to these
> requirements. I don’t think mapping any human system to any technology is
> clean and dry, but for what it’s worth I do see a lot of alignment.
>
>    - Given the nature of patient access rights, the provider is not in a
>       - ONC should clarify that API providers are not obligated to
>    a threat to the provider's own system. However, patients must be able
>    to override this suspension (except in the case where an app poses
>    1. To delegate a scope-limited access capability to anyone anywhere
> This will always be susceptible to the level of granularity that the API
> Provider allows the API to be accessed in.
>
> Standard APIs (which would result in standard “type” values in the
> “access” request array) can help with this by defining sufficient levels of
> detail. But ultimately, the user could never ask for a scope that the API
> Provider isn’t willing to express.
>
>
>    1. To allow the patient to automate the issue of a scope-limited
> This is where I think this discussion really should go. On the surface,
> this seems to lead to the “bring your own AS” model. I am contending that
> it’s more powerful to have an AS (still under the API Provider’s control)
> that allows the user to provide additional inputs during the protocol
> process. As an industry, we can standardize and innovate a lot of those
> inputs, but ultimately GNAP should be able to just connect those endpoints
> to each other (in my opinion). One of the common inputs is going to remain
> “get someone to log in at this webpage at the AS and click a button”, but
> I’m convinced there will be others.
>
>
>    1. The automation of the agent is based on policies provided by the
> In this case, shouldn’t it be that the agent is separated from the AS?
> Since the patient is going to have data protected by different API
> Provders, to me it stands to reason that they’d want the same agent acting
> for them on different systems. Each of those systems would still have its
> own AS, but the AS would be facilitated by the user’s input.
>
> Now this is NOT saying that the user would have their own AS to delegate
> something to the downstream AS. Or even saying that the user would have
> some kind of XACML policy server. I’m not sure exactly how the bits on the
> wire would work but a strawman would look something like:
>
>
>
> Client -> AS: hey I want to access this medical data; I can get the user
> to interact with you or I can put you in touch with their policy agent
>    1. To ensure that the requesting party can delegate the capability
> To facilitate this, the “agent” above can be augmented with other
> capabilities based on what’s being asked for. Adding a line to the flow
> above:
>
> Client -> AS: hey I want to access this medical data; I can get the user
> to interact with you or I can put you in touch with their policy agent
> *AS -> RO: It looks like someone's asking for an RS you have the approval
> for, that cool?*
> In other words, when the AS gets the request, it can and should take in
> inputs from multiple different dimensions in order to make the
> authorization decision and encode that into the access token.
>
>
>    1. To ensure that the API Provider does not censor the client app that
> This is one of the reasons that the AS-based model is really important in
> GNAP — the API Provider's RS only needs to know “is this token good for
> what’s being asked”.
>
>
>    1. If the API Provider decides, for any reason, to be “suspicious” (as
> If the AS can reach out to the patient through notice and consent, they
> can be brought into the process in an interactive way above. This assumes
> the AS has a way of connecting that, but we should assume the AS can
> provide this kind of notice and consent to parties that aren’t directly
> involved in the protocol flow in the same way the end user is.
>
>
>    1. The policies by which the patient or the decides to grant a
> In the above pattern, the AS and agent would need a way to communicate
> this with each other. I think the details of this are outside the scope of
> GNAP but it could take the form of a query/response fulfillment language.
> VC’s address part of this, but I think there will need to be other aspects
> brought to bear here. I think you could have a privacy-preserving protocol
> that would layer into GNAP here, but I don’t know for sure what that would
> look like.
>
>
>    1. Access requests to the agent are presumed confidential among the
> This would be a different kind of model, where the client would act as
> some kind of proxy in the process. Something more like:
>
>
> Client -> AS: hey I want to access this medical data; I can get the user
> to interact with you or I can forward your request details to the policy
> agent
> Client -> Agent: I have a request for data, at this AS, I need you to
> prove that you have the right to release this data
> For me the important part is that GNAP allow these kinds of trust
> connections. Even if GNAP isn’t solving every piece of this equation, it
> can at least clearly state “there’s a function here that needs to / is able
> to solve this thing” and build the important parts around it.
>
>
>  - Justin
>
>
> Adrian
>
>

---

From: Adrian Gropper <[email-masked]>
Date: Mon, 15 Mar 2021 22:12:21 -0400

Hi Justin,

I have exactly the same two questions as Fabien and also, I

On Mon, Mar 15, 2021 at 9:45 PM Fabien Imbault <[email-masked]>
wrote:

>> Hi Adrian, thanks so much for writing up this use case. I’ve included
>> some thoughts below into how different aspects of GNAP might map to these
>>    1. To ensure that the API Provider does not censor the client app
>>    1. If the API Provider decides, for any reason, to be “suspicious”

---

From: Adrian Gropper <[email-masked]>
Date: Mon, 15 Mar 2021 22:16:52 -0400

Hi Justin,

I have exactly the same two questions as Fabien and also, I worry about the
handwaving in the answer to 7.

Your flow for 8 doesn't make sense to me because I assume the client is on
the RO's mobile device and unavailable for most interactions. The whole
point of having the Agent is to keep the RO Client out of the picture when
the requesting party shows up with their Client.

Adrian

On Mon, Mar 15, 2021 at 10:12 PM Adrian Gropper <[email-masked]>
wrote:

>>>    - Given the nature of patient access rights, the provider is not in
>>> *AS -> RO: It looks like someone's asking for an RS you have the
>>> approval for, that cool?*
>>> This is one of the reasons that the AS-based model is really important
>>> in GNAP — the API Provider's RS only needs to know “is this token good for
>>> what’s being asked”.
>>>
>>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 16 Mar 2021 08:14:29 -0400

> On Mar 15, 2021, at 10:16 PM, Adrian Gropper <[email-masked]> wrote:
> 
> Hi Justin,
> 
> I have exactly the same two questions as Fabien and also, I worry about the handwaving in the answer to 7.

The handwaving is actually important. I don’t think that’s something that GNAP will solve in a universal way. We can have hooks in the core protocol that say “and now go do This Other Thing to talk to an agent”, but I don’t think we’re really the best ones to decide what that is or what it looks like for everyone. 

This could be DIDComm, it could be CHAPI, it could be some proprietary app connection with push notifications, it could be writing/reading from a shared encryption storage fabric — all that’s important here is that GNAP has a place in the protocol where these various things can fit. 

OAuth chose HTTP Redirects as The Way to get users involved in the process, but GNAP is taking a very different stance in trying to get away from that limiting assumption. I don’t think it would serve us to just make a different limiting assumption about how users (and their decisions) get involved.

To answer the questions;

> - we're covering the use case "get my medical data", how does that change if that's someone else's data? 

It’s the same process as the second flow. The RO is the patient or doctor or someone who can approve things. The AS doesn’t get everything that it needs to from the agent introduced by the client, so it needs to access another agent.

> - what happens if the agent can't guarantee availability? 

Then the AS doesn’t get what it needs in order to fulfill the request and it denies the request. Whether that’s a timeout or some other error, and whether that comes back to the client with a “try again” or with a “tough luck, go away”, I think that’s all up for debate, and parts of that we’ll need answers for. But ultimately, it’s the same kind of thing that happens in OAuth if the user doesn’t consent, or the user can’t log in, or the “wrong” user logs in for what’s being asked for — the AS isn’t satisfied with the approval so the delegation request fails.

> Your flow for 8 doesn't make sense to me because I assume the client is on the RO's mobile device and unavailable for most interactions. The whole point of having the Agent is to keep the RO Client out of the picture when the requesting party shows up with their Client.

The RO doesn’t have a client in any of the flows below. The RO might have an agent, they might have an app that notifies them to go log into a webpage asynchronously, they might get an email with a link to click back at the AS. None of that is facilitated through the RO’s client because the RO doesn’t have a “client” in this model. The client is by definition the software in front of the “user”, the requesting party. 

And it’s important in the design that the client doesn’t need to know about any of that. It can identify the resource, possibly identify the RO, and it can tell the AS “this is how I can talk to the person sitting in front of me right now” — for whatever definition of “talk to” makes sense for the client app. What it can’t reliably do is say “this is how I can get in touch with an RO that I’m not talking to”, and certainly not communicate with another client, another AS, or other part of the GNAP protocol. 

 - Justin

> 
> Adrian
> 
> On Mon, Mar 15, 2021 at 10:12 PM Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Justin,
> 
> On Mon, Mar 15, 2021 at 9:45 PM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Justin
> 
> A few questions :
> - we're covering the use case "get my medical data", how does that change if that's someone else's data? 
> Le lun. 15 mars 2021 à 20:42, Justin Richer <[email-masked] <mailto:[email-masked]>> a écrit :
>> On Mar 12, 2021, at 4:34 PM, Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 16 Mar 2021 14:19:41 +0100

Hi Justin,

My comments in red [FIM].

Cheers
Fabien

On Tue, Mar 16, 2021 at 1:14 PM Justin Richer <[email-masked]> wrote:

> The handwaving is actually important. I don’t think that’s something that
> GNAP will solve in a universal way. We can have hooks in the core protocol
> that say “and now go do This Other Thing to talk to an agent”, but I don’t
> think we’re really the best ones to decide what that is or what it looks
> like for everyone.
>
> This could be DIDComm, it could be CHAPI, it could be some proprietary app
> connection with push notifications, it could be writing/reading from a
> shared encryption storage fabric — all that’s important here is that GNAP
> has a place in the protocol where these various things can fit.
>
> OAuth chose HTTP Redirects as The Way to get users involved in the
> process, but GNAP is taking a very different stance in trying to get away
> from that limiting assumption. I don’t think it would serve us to just make
> a different limiting assumption about how users (and their decisions) get
> involved.
>

[FIM] We shouldn't be looking for an universal carrier, I agree, but people
will need practical ways to implement that. I think there's a fine line
between avoiding limiting assumptions and GNAP remaining too conceptual. At
least we should know where to put the extension points.

> It’s the same process as the second flow. The RO is the patient or doctor
> or someone who can approve things. The AS doesn’t get everything that it
> needs to from the agent introduced by the client, so it needs to access
> another agent.
>

> Then the AS doesn’t get what it needs in order to fulfill the request and
> it denies the request. Whether that’s a timeout or some other error, and
> whether that comes back to the client with a “try again” or with a “tough
> luck, go away”, I think that’s all up for debate, and parts of that we’ll
> need answers for. But ultimately, it’s the same kind of thing that happens
> in OAuth if the user doesn’t consent, or the user can’t log in, or the
> “wrong” user logs in for what’s being asked for — the AS isn’t satisfied
> with the approval so the delegation request fails.
>

[FIM]  seems realistic when user = RO, the end-user can make itself
available if the service is really important to him. "Tough luck" at first
failure is fine then.
But I believe that becomes impractical when a remote RO is involved (at
least if it's supposed to be a human: if we don't deal with unavailability,
async sequence 1.4.3 should be removed).

> The RO doesn’t have a client in any of the flows below. The RO might have
> an agent, they might have an app that notifies them to go log into a
> webpage asynchronously, they might get an email with a link to click back
> at the AS. None of that is facilitated through the RO’s client because the
> RO doesn’t have a “client” in this model. The client is by definition the
> software in front of the “user”, the requesting party.
>
[FIM] yes indeed

>
> And it’s important in the design that the client doesn’t need to know
> about any of that. It can identify the resource, possibly identify the RO,
> and it can tell the AS “this is how I can talk to the person sitting in
> front of me right now” — for whatever definition of “talk to” makes sense
> for the client app. What it can’t reliably do is say “this is how I can get
> in touch with an RO that I’m not talking to”, and certainly not communicate
> with another client, another AS, or other part of the GNAP protocol.
>

[FIM] Not entirely clear where we draw the line. I imagine "person sitting
in front of me right now" is not to be taken literally? (could be my
doctor, even if he's not in the same room).
Clearly there's no way a client can ever guarantee a reliable communication
with something else, I agree. At the very best it's a hint (and possibly a
bad one).

>>>> This will always be susceptible to the level of granularity that the
>>>> API Provider allows the API to be accessed in.
>>>>
>>>> Now this is NOT saying that the user would have their own AS to
>>>> delegate something to the downstream AS. Or even saying that the user would
>>>> have some kind of XACML policy server. I’m not sure exactly how the bits on
>>>> the wire would work but a strawman would look something like:
>>>>
>>>>
>>>>
>>>> Client -> AS: hey I want to access this medical data; I can get the
>>>> user to interact with you or I can put you in touch with their policy agent
>>>> Client -> AS: hey I want to access this medical data; I can get the
>>>> user to interact with you or I can put you in touch with their policy agent
>>>> Client -> AS: hey I want to access this medical data; I can get the
>>>> user to interact with you or I can forward your request details to the
>>>> policy agent

---

From: Justin Richer <[email-masked]>
Date: Tue, 16 Mar 2021 10:11:29 -0400

Responses inline..

> On Mar 16, 2021, at 9:19 AM, Fabien Imbault <[email-masked]> wrote:
> 
> Hi Justin,
> 
> On Tue, Mar 16, 2021 at 1:14 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 15, 2021, at 10:16 PM, Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Justin,
>> 
> [FIM] We shouldn't be looking for an universal carrier, I agree, but people will need practical ways to implement that. I think there's a fine line between avoiding limiting assumptions and GNAP remaining too conceptual. At least we should know where to put the extension points.

I agree that we need to have the extension points in the right place. In order to do that, we need to know what we’re extending, which was the impetus for starting this conversation. It’s debatable how much further we want to go beyond that in GNAP itself, especially since there are a lot of other protocols out there designed to fit this niche well (see examples above). 

One step we definitely can help with is providing a cohesive model for describing both people and access rights, and being clear about the overall process.

> [FIM]  seems realistic when user = RO, the end-user can make itself available if the service is really important to him. "Tough luck" at first failure is fine then. 
> But I believe that becomes impractical when a remote RO is involved (at least if it's supposed to be a human: if we don't deal with unavailability, async sequence 1.4.3 should be removed). 

Then, what is the AS to do if it tries the methods necessary to reach the RO, but those methods fail? Or if there are multiple RO’s who could approve and multiple come back? 

I agree that these are situations the AS is going to have to deal with, but I also believe that the details of what gets us into these situations is outside of GNAP itself. Perhaps think of it this way:

 - The AS needs to gather authorization and consent.
 - The client can direct interaction with the end user.
 - The end user might be able to provide that authorization and consent.
 - The client doesn’t know if the end user is the RO, but it can provide the AS with hints as to who the end user is and means to interact with them for the AS.
 - The AS knows who the RO is and might have ways to interact with them (and their decisions) outside of the interface with the client.

So in other words, the consent-gathering process that the AS goes through can be both client-mediated and non-client-mediated. The client-mediated portions are very much in scope of GNAP and they fall into the space of user == RO very easily. The non-client-mediated interactions are outside the scope of GNAP — or at least outside the core protocol, since the core protocol is all about the client instance getting a token (and/or subject info).

I think we can expand the discussion in the draft of how the AS goes through this consent gathering process but shouldn’t try to define one specific way of it happening. That way we can define good behavior around asynchronous methods, timeouts, and multi-user protocols, but without having to define, say, a wire-based policy language to carry those decisions. It’s definitely a fine line!

> [FIM] Not entirely clear where we draw the line. I imagine "person sitting in front of me right now" is not to be taken literally? (could be my doctor, even if he's not in the same room).
> Clearly there's no way a client can ever guarantee a reliable communication with something else, I agree. At the very best it's a hint (and possibly a bad one).

If the doctor isn’t using the client application, then the doctor’s not the “user” in protocol terms. If the AS has some other way to get the doctor involved, it should be able to do that, but the client can’t really do anything about it.

 - Justin

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 16 Mar 2021 15:59:55 +0100

Same, thanks for the clarification.

On Tue, Mar 16, 2021 at 3:11 PM Justin Richer <[email-masked]> wrote:

>> This could be DIDComm, it could be CHAPI, it could be some proprietary
>> app connection with push notifications, it could be writing/reading from a
> [FIM] We shouldn't be looking for an universal carrier, I agree, but
> people will need practical ways to implement that. I think there's a fine
> line between avoiding limiting assumptions and GNAP remaining too
> conceptual. At least we should know where to put the extension points.
>
>
> I agree that we need to have the extension points in the right place. In
> order to do that, we need to know what we’re extending, which was the
> impetus for starting this conversation. It’s debatable how much further we
> want to go beyond that in GNAP itself, especially since there are a lot of
> other protocols out there designed to fit this niche well (see examples
> above).
>
> One step we definitely can help with is providing a cohesive model for
> describing both people and access rights, and being clear about the overall
> process.
>

[FIM2] clearer to me, thanks.

> Then, what is the AS to do if it tries the methods necessary to reach the
> RO, but those methods fail? Or if there are multiple RO’s who could approve
> and multiple come back?
>
[FIM2] yes, that's some of the cases (and open questions) I put forward in
the presentation, trying to identify what would have to be dealt with.
It would be fine to decide all interactions need to be synchronous
requests/responses in the core.

>
> I agree that these are situations the AS is going to have to deal with,
> but I also believe that the details of what gets us into these situations
> is outside of GNAP itself. Perhaps think of it this way:
>
>  - The client doesn’t know if the end user is the RO, but it can provide
> the AS with hints as to who the end user is and means to interact with them
> for the AS.
>  - The AS knows who the RO is and might have ways to interact with them
> (and their decisions) outside of the interface with the client.
>
> So in other words, the consent-gathering process that the AS goes through
> can be both client-mediated and non-client-mediated. The client-mediated
> portions are very much in scope of GNAP and they fall into the space of
> user == RO very easily. The non-client-mediated interactions are outside
> the scope of GNAP — or at least outside the core protocol, since the core
> protocol is all about the client instance getting a token (and/or subject
> info).
>
[FIM2] that could be a viable way to refine the scope of the core. As long
as it's clear what we do, it's fine to me.

>
> I think we can expand the discussion in the draft of how the AS goes
> through this consent gathering process but shouldn’t try to define one
> specific way of it happening. That way we can define good behavior around
> asynchronous methods, timeouts, and multi-user protocols, but without
> having to define, say, a wire-based policy language to carry those
> decisions. It’s definitely a fine line!
>
[FIM2] yes, for sure DIDComm was in my view just one example of a possible
extended interact method (among many possible already today and more in the
future).
In practice, none of those non-client-mediated interactions need to be in
the core. However, they would probably require that GNAP defines how one
should react to such async or message based patterns, above the underlying
protocol foundation, to provide "elegant, synchronous request-response
interactions." (as said in 1.3.1 of DIDComm). Defining good async behaviour
without minimal syntax is possible with coloring schemes, but they have
their drawbacks too (forces you to always think in colors, even for basic
sync cases, and so I'm not convinced that would be a win).

> Clearly there's no way a client can ever guarantee a reliable
> communication with something else, I agree. At the very best it's a hint
> (and possibly a bad one).
>
>
> If the doctor isn’t using the client application, then the doctor’s not
> the “user” in protocol terms. If the AS has some other way to get the
> doctor involved, it should be able to do that, but the client can’t really
> do anything about it.
>
>  - Justin
>
>
>>  - Justin
>>
>>
>> Adrian
>>
>>>>>    - Given the nature of patient access rights, the provider is not
>>>>>    1. To delegate a scope-limited access capability to anyone
>>>>>    anywhere without having to explain or justify that to the API Provider.
>>>>>
>>>>>
>>>>> This is where I think this discussion really should go. On the
>>>>> surface, this seems to lead to the “bring your own AS” model. I am
>>>>> contending that it’s more powerful to have an AS (still under the API
>>>>> Provider’s control) that allows the user to provide additional inputs
>>>>> during the protocol process. As an industry, we can standardize and
>>>>> innovate a lot of those inputs, but ultimately GNAP should be able to just
>>>>> connect those endpoints to each other (in my opinion). One of the common
>>>>> inputs is going to remain “get someone to log in at this webpage at the AS
>>>>> and click a button”, but I’m convinced there will be others.
>>>>>
>>>>>
>>>>>    1. The automation of the agent is based on policies provided by
>>>>>    the patient. The agent is able to process access requests from anyone and
>>>>>    is responsible only to the patient. The agent responds to successful
>>>>>    requests by issuing a filtered capability to the requesting party.
>>>>>
>>>>>
>>>>> In other words, when the AS gets the request, it can and should take
>>>>> in inputs from multiple different dimensions in order to make the
>>>>> If the AS can reach out to the patient through notice and consent,
>>>>> they can be brought into the process in an interactive way above. This
>>>>> assumes the AS has a way of connecting that, but we should assume the AS
>>>>> can provide this kind of notice and consent to parties that aren’t directly
>>>>>    1. Access requests to the agent are presumed confidential among
>>>>>    the patient, the agent, and whatever client the requesting party uses to

---

From: Adrian Gropper <[email-masked]>
Date: Tue, 16 Mar 2021 11:04:06 -0400

I share the goal of finding the appropriate extension points but I'm having
a hard time following the conversation because we're not talking about the
specific use case.

Let me try and recap:
- The doctor is live and using a client application to place a request to
an AS that pertains to a particular RO as the subject.
- The RO has delegated authorization to an on-line agent and the RO
themselves may be offline.
- Any of the various actors in the GNAP protocol may raise warnings or
exceptions and could try to reach the RO if provided with appropriate
hints. The actual mechanisms for contacting the RO are likely out of scope
for GNAP but we do need to consider the extension points and hints for some
or all actors we do identify in the GNAP spec.
- Given the above, Justin is proposing that the AS and the agent are
separate actors, both online, and need to interact in order to turn the
doctor's request into an authorization token.
- This interaction between the AS and the agent is clearly at the heart of
GNAP and how we explain GNAP to others.
- If the RO's policies are in one actor (the agent) and the request is
presented to another actor (the AS) then GNAP becomes a protocol for how an
agent interacts with an AS.
- The capability to be turned into an authorization token originates with
the RS-RO relationship. It could have been given to the RO, the agent, or
the AS initially. Some of these might be out of scope for GNAP and others
need to be specified.
- The capability to issue an authorization needs is the third essential
component of GNAP along with policies (at the agent) and a request receipt
endpoint (of the AS).
- The RO has a privacy interest in getting the request in a way that the AS
does not benefit from.

GNAP must not force the agent to share request information with anyone that
is not a principal to the transaction. Those principals are the RO, their
agent, and the RS.

Adrian

On Tue, Mar 16, 2021 at 11:00 AM Fabien Imbault <[email-masked]>
wrote:

>>> The handwaving is actually important. I don’t think that’s something
>>> that GNAP will solve in a universal way. We can have hooks in the core
>>> protocol that say “and now go do This Other Thing to talk to an agent”, but
>>> I don’t think we’re really the best ones to decide what that is or what it
>>> looks like for everyone.
>>>
>>> It’s the same process as the second flow. The RO is the patient or
>>> doctor or someone who can approve things. The AS doesn’t get everything
>>> that it needs to from the agent introduced by the client, so it needs to
>>> access another agent.
>>>
>>
>>> Then the AS doesn’t get what it needs in order to fulfill the request
>>> and it denies the request. Whether that’s a timeout or some other error,
>>> and whether that comes back to the client with a “try again” or with a
>>> “tough luck, go away”, I think that’s all up for debate, and parts of that
>>> we’ll need answers for. But ultimately, it’s the same kind of thing that
>>> happens in OAuth if the user doesn’t consent, or the user can’t log in, or
>>> the “wrong” user logs in for what’s being asked for — the AS isn’t
>>> satisfied with the approval so the delegation request fails.
>>>
>>
>> Your flow for 8 doesn't make sense to me because I assume the client is
>>> on the RO's mobile device and unavailable for most interactions. The whole
>>> The RO doesn’t have a client in any of the flows below. The RO might
>>> have an agent, they might have an app that notifies them to go log into a
>> [FIM] Not entirely clear where we draw the line. I imagine "person
>> sitting in front of me right now" is not to be taken literally? (could be
>> my doctor, even if he's not in the same room).
>>>> On Mon, Mar 15, 2021 at 9:45 PM Fabien Imbault <
>>>>>> In this case, shouldn’t it be that the agent is separated from the
>>>>>> AS? Since the patient is going to have data protected by different API
>>>>>>    1. To ensure that the requesting party can delegate the
>>>>>>    capability using an institutional workflow system that they trust and the
>>>>>>    patient doesn’t know or care about. In many cases, the workflow system will
>>>>>>    pass the capability to some other person, who we might call the end user.
>>>>>>    In other cases, the requesting party may forward the capability directly to
>>>>>> This is one of the reasons that the AS-based model is really
>>>>>> important in GNAP — the API Provider's RS only needs to know “is this token
>>>>>> good for what’s being asked”.
>>>>>>
>>>>>>
>>>>>>    1. If the API Provider decides, for any reason, to be
>>>>>>    “suspicious” (as above) of the access transaction based on the information
>>>>>>    it has, it should be possible for the API Provider to warn the patient and
>>>>>>    to accept an override of the warning by the patient. This effectively means
>>>>>>    that the end-user will provide as much information as they think will be
>>>>>>    necessary in order to either avoid “suspicion” or risk waiting for patient
>>>>>>    override.
>>>>>>
>>>>>>
>>>>>> In the above pattern, the AS and agent would need a way to
>>>>>> communicate this with each other. I think the details of this are outside
>>>>>> the scope of GNAP but it could take the form of a query/response
>>>>>> fulfillment language. VC’s address part of this, but I think there will
>>>>>> need to be other aspects brought to bear here. I think you could have a
>>>>>> privacy-preserving protocol that would layer into GNAP here, but I don’t
>>>>>> know for sure what that would look like.
>>>>>>
>>>>>>
>>>>>> This would be a different kind of model, where the client would act
>>>>>> as some kind of proxy in the process. Something more like:
>>>>>>
>>>>>>