Re: RqP presenting W3C Verifiable Credentials to an UMA Authorization Server

Hi Adrian

regarding your trust relationships, I would say that

2) is really trust in the cryptography. If the crypto cannot be broken
then it is not possible to tamper with the VC without it being detected.

3) is an issuer trust issue. The issuer trusts the holder not to misuse
the issued credential(s), but actually cannot tell because the holder
can present it/them to any verifier he/she wants to. The verifier trusts
the issued VCs to tell it who the holder is, so can only tell if the VCs
are being misused or not by reading the VCs' contents (e.g. terms of use).

Regards

David

On 20/10/2018 04:53, Adrian Gropper 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
> <mailto: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/

Received on Sunday, 21 October 2018 21:23:36 UTC