RqP presenting W3C Verifiable Credentials to an UMA Authorization Server

I'm cross posting this for the obvious reason and will try to act as relay
if a discussion ensues.

On today’s UMA standards call, the following came up:
180 degrees use case / decoupled use case discussion

Nancy has written up some "180 degrees" use cases, which she'll share more
widely soon. These got Eve thinking.

We briefly discussed use cases where the requesting party needs to trust
the resource owner before taking some action (potentially against resources
shared), e.g. a loan officer needing to trust that the putative resource
owner is who they say they are so that the (e.g.) personal attributes
(resource) shared can be trusted to be associated with that resource owner
"bearer". This way, the loan officer can approve a loan (which might be a
second resource that the same resource owner could later share with others).

The current UMA model allows the RO and their AS to match RqP claims (not
just a plain authenticated identity) against policy, and the RO can be
decoupled (asynchronous) from that process. The client that the RqP uses is
explicitly accounted for in the protocol, and UMA has a framework for this
matching and for the RO's delegation / access granting to the RqP. But it
only accounts for the client that the RO uses to interact with the RS and
AS through the OAuth authorization endpoint (resulting in a PAT), and
otherwise the client handling on the RO side is implicit.

The notion of the RqP needing to trust the RO and the RO needing to grant
resource access to the RqP seems similar to the "decoupled" use cases,
where a CSR or bank teller needs to know that Alice is really Alice before
getting access to her account.

What would make sense for ensuring that the RqP could come to trust the RO
"binding"? Alec will describe some work they've done along these lines in
our next meeting.

For the UMA folks, check out Figure 2 at
https://www.w3.org/TR/verifiable-claims-data-model/ to get oriented. For
the VC folks, check out
https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html
by way of orientation.

Our HIE of One Trustee implementation would not be practical without _both_
UMA authorization and self-sovereign identifier standards. Federation in
healthcare is not deployed widely enough to serve a patient-centric health
record application. I hope this email inspires our group’s to harmonize or
at least to produce a brief paper describing why or why not.

Adrian



-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: https://patientprivacyrights.org/donate-3/