Re: [WG-UMA] RqP presenting W3C Verifiable Credentials to an UMA Authorization Server

I think Alec and I agree to the limit of our terminology and my
understanding.

As I participate in both the UMA and VC groups, there has been a lot of
discussion of:
- on the UMA legal side, the value of distinguishing the technical entity
(AS) from the legal operator entity (ASO)
- on the VC side, the subject = holder vs. subject .ne. holder

Since both initiatives depend on legal clarity for success, it would be
really nice if we could come to a common set of definitions.

Adrian


On Sun, Oct 21, 2018 at 8:23 AM Alec Laws <alec@identos.ca> wrote:

> Hi,
>
> Think we agree on the entities, but may not on the definition of a VC
> Holder. I don't believe the AS is a holder because it never touches the
> VC's, only authorizes their movement between RS & RqP. From [1], 'Holders
> must receive and store verifiable claims'
>
> path 1: [Issuer] RS--VC-->RqP [Holder(Wallet)] RS--VC-->RqP [Verifier]
> path 2: [Issuer/Holder] RS--VC-->RqP [Verifier]
>
> As Adrian suggests, path 1 is more privacy respecting because the Issuer
> doesn't control how Alice may use the VC after it’s issued. In either path,
> the Verifier trusts the claim based on the Issuer's signature.
> UMA allows path 2 where the holder doesn't exist, or is pary of the
> Issuer.
>
> Best,
> Alec Laws
> alec@identos.ca
>
>
> [1] Verifiable Claims Data Model and Representations
>
> On Oct 20, 2018, at 5:19 PM, Adrian Gropper <agropper@healthurl.com>
> wrote:
>
> Continuing to cross-post Alec's next contribution below and adding:
>
> - Alec seems to agree to the 4 rust issues so let's work with them until
> something else comes up.
>
> - I think I disagree with Alec on the Holder / RS pairing in a subtle way.
> If, for privacy reasons, the VC should not need to know how and when the VC
> is used, (the Driver's License Bureau doesn't know or care when you use
> your driver's license) then the AS should be in charge of the wallet and
> operated by the RO. In some cases, the AS will decide to send the RqP's
> Client directly to the RS (a privacy issue for the RO) but in other cases,
> the AS will decide to send the RqP to a RS (a wallet) that is operated by
> the RO.
>
> This is exactly how Trustee functions today. The AS is paired with a
> RO-controlled EHR acting as a holder / wallet. There's no loss of privacy
> or sovereignty because the RO-controlled AS can always choose whether to
> send a request to the issuer's RS or to a copy of the credential in the
> RO's RS.
>
> Adrian
>
> Hi,
>>
>> The 4 trust issues seems correct. For the pairings, instead of AS as
>> holder, is that role fulfilled by the RS? Maybe both models are correct in
>> different constructions?
>>
>> *Holder / RS*
>> Subject / RO
>> Issuer / RS, or out of UMA scope
>> Verifier / RqP
>> Identifier registry / AS?
>>
>> With these pairings, there are two issues mapping UMA to VC
>>
>>    1. The RS is either issuer or holder (or both issuer and holder).
>>    When an RS issues claims a  ‘wallet RS’ may act as a client with the
>>    subject/RO as the RqP. After collecting and holding the claim, it will
>>    later present it to a RqP, now acting in the RS role. The RS is the holder
>>    / wallet of VCs on behalf of the subject (RO).
>>
>>
>>    1. In UMA the RO might not be present during claim presentation.
>>    Instead the RO may have created a policy at an AS, allowing a RqP to access
>>    their VC. The RS is the entity which actually presents the claims to the
>>    RqP (and would need pop, either dynamically or pre-provisioned by the
>>    subject?).
>>
>>
>> Trustee Example: The institution (Labcorp) issues the VC directly to the
>> Licensed Physician, based on a Policy created by the Patient at the RS.
>> Eve’s Example: The State License Bureau issues the Digital Driver's
>> License to the loan officer.
>>
>> In both examples, the VC may first go to a 'wallet RS' that the subject
>> controls first. During presentation to the RqP that wallet performs like an
>> RS with authorization from the AS.
>>
>> Are there issues with the same entity performing multiple roles in the VC
>> model?
>> Also, how does the RqP knows which resource to request from the RS? In
>> the VC model this is clear since the entity presenting the claims is the
>> subject/holder
>>
>>
>> Alec Laws
>> alec@identos.ca
>>
>>
>>
>> On Oct 19, 2018, at 11:53 PM, Adrian Gropper <agropper@healthurl.com>
>> wrote:
>>
>> Continuing the cross-posting to make sure David's excellent analysis is
>> seen by all...
>>
>> HIE of One Trustee is a self-sovereign technology use-case designed to
>> work where federations are faltering or distorting the market.
>>
>> *Analog      VC          UMA          Trustee Example               Eve's
>> Example                   *
>>
>> Patient     Subject     RO           Patient                       Bank
>> Customer
>>
>> HIV Titer   Issuer      RS           Institution (e.g. Labcorp)    State
>> License Bureau (digital)
>>
>> Wallet      Holder      AS           Trustee (an UMA AS)           AS
>> (customer's digital agent)
>>
>> HIV Report  VC          Resource     FHIR Resource
>> Digital Driver's License
>>
>> Blood Bank  Verifier    RqP          Licensed Physician            Bank
>> Clerk or Loan Officer
>>
>>
>> *Trust relationships:*
>> (1) The Verifier / RqP trusts that the Issuer / RS properly identified
>> the Subject / RO - Liability may rest with the Issuer, the Verifier, or the
>> Subject depending on the use-case.
>>
>> (2) The Verifier / RqP trusts that the Holder / AS has not tampered with
>> the credential.
>>
>> (3) The Verifier / RqP trusts that the Holder / AS operator will not
>> misuse the claims they present in order to gain authorization to the
>> resource.
>>
>> (4) The Verifier / RqP can, acting as an Issuer / RS, issue a secondary
>> credential (e.g. a prescription) to the Holder / AS that some downstream
>> Verifier / RqP will trust.
>>
>> Are 1-4 the only trust issues under consideration?
>>
>> Are the pairings  Subject / RO,  Issuer / RS, Holder / AS, Verifier / RqP
>> universal enough to be helpful in our standards efforts?
>>
>> Adrian
>>
>>
>>
>> On Fri, Oct 19, 2018 at 5:22 PM David Chadwick <D.W.Chadwick@kent.ac.uk>
>> wrote:
>>
>>> Hi Adrian
>>>
>>> in the VC work the verifier trusts the issuer(s) of the VCs, not the
>>> holder.
>>>
>>> Translating the VC model into UMA language, the VC verifier is the UMA
>>> requesting party, the UMA protected resource would be the VC holder's
>>> wallet holding his/her VCs. The UMA resource owner is the VC holder. The
>>> VC issuer is not in the UMA diagram in Figure 1: Federated Authorization
>>> Enhancements to UMA Grant Flow.
>>>
>>> If you add this missing entity(ies), namely the VC issuer(s) into your
>>> diagram, and indicate that the requesting party trusts the VC issuer(s),
>>> then the requesting party can determine whether the resource owner can
>>> be trusted or not after validating the VCs.
>>>
>>> Note that VCs do not generally use bearer tokens, and the holder has to
>>> prove that he/she is the genuine holder of the issued VCs. This PoP
>>> might mean you need an enhancement to the UMA protocol (I dont know the
>>> UMA protocol in detail. You may already have PoP). One way is for the AS
>>> or RS to hold the RO's private keys and to sign the response message to
>>> the requesting party.
>>>
>>> regards
>>>
>>> David
>>>
>>> On 19/10/2018 19:20, Adrian Gropper wrote:
>>> > 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/
>>>
>>
>>
>> --
>>
>> 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/
>> _______________________________________________
>> WG-UMA mailing list
>> WG-UMA@kantarainitiative.org
>> https://kantarainitiative.org/mailman/listinfo/wg-uma
>>
>>
>>
>
> --
>
> 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/
>
>
>