Re: [GNAP] generic HTTP resource type

[Adrian Gropper <[e-mail]>]

Hi Jamey,

tldr: My perspective in the GNAP discussion is to maximize the power of the
RO and minimize the power of the RS by assuming that the RO can delegate to
_any_ AS they choose.

I'm grateful for your conversation because you are helping me tease out
which aspects of GNAP are essential for my (fairly common) use-case. My
use-case is securing a very complex (HL7-FHIR [1]) and regulated (US Gov
API Task Force [2]) API to health records. This work has been evolving for
a decade or more in the Kantara UMA WG [3] and the OpenID HEART WG [4] with
almost zero commercial uptake.

My goal is to use GNAP to replace as much of the OAuth, UMA, and OIDC
example implementation of delegated health records access. Links to our
repos are on the last slide of yesterday's presentation [5].

continuing inline....

On Tue, Jul 27, 2021 at 2:25 PM Jamey Sharp <[e-mail]> wrote:

> Hi Adrian!
>
> I agree with the general principles you're suggesting, but I don't
> believe my proposal reveals anything new to the RS. A resource server
> has to know what resource the end-user is requesting in order to serve
> that resource.
>
Yes.

>
> (The cryptography notions of "private information retrieval" and
> "oblivious RAM" would be an interesting challenge to apply to the web,
> but I'm sure they're well out of scope for this WG. You might enjoy
> reading the research literature on them though.)
>
Sure. My concern is RO power and control, not security.

>
> My proposal does potentially reveal new information to the AS, and
> that's worth thinking about. There are two cases:
>
No problem. I want to maximize the ROs agency by giving their delegated AS
as much power (privilege or capability) as the RO wants.

>
> If it's desirable for the AS to reveal to the end-user the set of
> resources to which they've been granted rights—and I think it is—then
> that means the RS must have previously informed the AS about what the
> resource references which the RS uses actually refer to. Otherwise, a
> reference is an opaque string like "WallyWorld" that means nothing to
> either the end-user or the AS. (It certainly doesn't mean anything to
> me: I'm taking that from the original examples in the HTTP Basic auth
> spec, going back to at least 1996.)
>
Yes. Seems obvious.

>
> Second, I've proposed that the client inform the AS of the specific
> resource and method which the end-user was trying to request. I'm not
> sure whether that's either necessary or desirable; I'm hoping other
> folks will chime in on my questions about whether the client needs to be
> able to indicate that it understands this generic "http" rights type.
>
Yes. I have no problem with AS, as the RO's agent, being informed to the
extent the end-user is willing to share their attributes and their intent.

>
> I think it's worth noting that the choice of AS is made by the RO/RS,
> not by the end-user. So the safest assumption you can make when
> analyzing the privacy properties of GNAP is that the RS and AS may
> reveal any information they have to each other without the end-user's
> knowledge or consent. That doesn't change the above analysis though,
> since the only things the AS may learn are things the RS already knows.
>
Careful. "Separation of Concerns", avoiding censorship, and data
minimization dictate that the choice of AS should be made by the RO.  If an
RS is unwilling or unable to allow the RO their free choice of agent then I
would suggest that the RO should copy the resource to an RS that does allow
them to choose the AS.

As to the information transfer between AS and RS, it makes a big difference
if the end-ser is the RO or not.

>
> Finally, here's context I think will help you on HTTP authentication:
>
> An HTTP server can indicate that its response to a resource request
> might change if the client were authenticated. It does so by sending a
> "WWW-Authenticate" response header, containing a list of authentication
> schemes that the server will accept. In the context of GNAP, you can see
> that in "RS-first Method of AS Discovery", currently section 9.1.
>
 OK.

>
> If the client chooses to use one of those schemes, then it sends a new
> request containing an "Authorization" header. The contents of that
> header are mostly specified by the selected authentication scheme; for
> GNAP, that's covered in "Securing Requests from the Client Instance",
> "Presenting Access Tokens", which is currently section 7.2.
>
OK.

>
> GNAP departs from older HTTP authentication schemes because in between
> the above two steps, the client goes off and talks to somebody else (the
> AS) for a while. But that side conversation is invisible to the RS,
> which just sees the client send one unauthenticated request and then a
> second request that contains an access token.
>
An unauthenticated request to the RS may return a pointer to the AS
controlling that resource if the RO wants to allow RS-first flows.
Otherwise, discovery of the AS and resources associated with the RO should
be out of scope for GNAP.

If the client already knows that the RS uses a specific GNAP AS, then
> the RS doesn't even get that first unauthenticated request; the first
> time it hears anything from the client is after the conversation with
> the AS is finished. But I'm interested in the case where the client has
> no prior knowledge about the RS, which means it works as I've described
> above, just like any other HTTP auth scheme.
>
I think we agree, as above.

>
> The problem I'm trying to address is that after the first request, the
> HTTP auth spec doesn't say whether the client should use the same
> credentials when requesting resources at other URLs.
>
This is above my pay grade.

>
> If the client does not send credentials on the next request, then it may
> get another "WWW-Authenticate" header back without getting the resource
> it actually wanted, which wastes time as it has to issue the request
> again even if it has a valid access token available.
>
In general, "wasting time" is not my concern. I'm on the lookout for giving
the RO maximum agency over the RS and if that's seen as a cost, so be it.

>
> But proactively authenticating to a different URL can leak information
> to a malicious party, since there may be many unaffiliated ROs at a
> single RS. For the Basic and Bearer schemes, the leaked information is
> full credentials and a complete security compromise. In other schemes,
> revealing that the end-user has credentials for some other resources is
> still a privacy violation, and in addition the leaked information may
> include identity details such as a username.
>
I'm not sure of this. In general, end-user credentials should not be the
concern of the RS. For the RS as (GDPR) "processor", there are two
possibilities:
(a) The RS has some prior understanding of the RO's identity and can
associate authentication credentials with that identity.
(b) The RS has no prior understanding of the RO identity and simply takes a
key or certificate on a Trust on First Use basis.

>
> I briefly discussed in my previous mail how the Basic and Digest schemes
> approach this. Bearer seems to assume the client has prior knowledge
> about which resources a token gives it access to—which is reasonable
> given how OAuth 2.0 has been used, but GNAP's RS-first discovery opens
> up new use cases with new challenges. So I believe this needs to be
> addressed somehow, and I've proposed one possible way to do it.
>
I hope my answers above have helped. You may be raising a security issue
that does not imply any power shift between the RO and the RS. In cases
where the end-user is not the RO, the end-user has legitimate privacy
interests relative to both the RS and AS but I don't understand if your
proposal impacts this.

- Adrian

>
>
> I hope this clarified my proposal for you!
> Jamey
>


[1] https://www.hl7.org/fhir/
[2]
https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-APITFRecommendations.pdf

[3] https://kantarainitiative.org/confluence/display/uma/Home
[4] https://openid.net/wg/heart/
[5]
https://datatracker.ietf.org/meeting/111/materials/slides-111-gnap-gnap-and-w3c-verifiable-credentials-api-01

- Adrian