Guidance on bridging OAuth RS to GNAP

[agropper]

OAuth is de-facto mandated for RS APIs in healthcare and other application domains. In previous work we demonstrated a patient-controlled bridge between OAuth-secured health records (stored in US-standard hospital records as well as US-Medicare insurance claims) and a UMA2 patient-controlled authorization server and a UMA-secured health record. Regulatory mandates for a patient's right of access are a common basis for client registration in institutional OAuth systems.

Consider a bridge between the Alice-to-Alice and Alice-to-Bob use-cases. Would it be a good idea for GNAP to include non-normative guidance on how Alice's GNAP AS can also act as Alice's OAuth Client to mediate or proxy a resource request by Bob?

[jricher]

Speaking as an individual, I don't see a lot of value in including this, especially in the core specification. This type of proxied scenario is reasonable enough to deploy, and it fits GNAP's general model of the AS as a token factory -- the AS can gather its materials from a number of places including some other upstream AS that may speak different protocols. However, doing that doesn't change how GNAP gets used downstream with alice's Client and RS, right? If it did then we'd want to talk about it. If not, then it's best relegated to blog posts, use case wikis, and online discussions, in my opinion.

[agropper]

There are two clients in this use-case. Alice has a mandated right to use her client, any client, to talk to the RS. Alice has no control over Bob’s client and, in many cases such as an employer’s IT system, neither does Bob.

It’s not obvious how GNAP should be used in this case.

[jricher]

Discussed on editors' call, it would be helpful to the discussion if you could provide actual text that would address this use case.

[jricher]

No text has been proposed for this use case, closing the issue.