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.... 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/
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.... 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/
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....
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/
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 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). 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 <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/ <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.... <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/ <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/ <https://patientprivacyrights.org/donate-3/>_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma
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....
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/
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 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). 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 <mailto:alec@identos.ca>
On Oct 19, 2018, at 11:53 PM, Adrian Gropper <agropper@healthurl.com <mailto: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 <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/ <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.... <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/ <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/ <https://patientprivacyrights.org/donate-3/>_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> https://kantarainitiative.org/mailman/listinfo/wg-uma <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/ <https://patientprivacyrights.org/donate-3/>
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
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
On 19/10/2018 19:20, Adrian Gropper wrote: 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....
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/
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.... > 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/
participants (3)
-
Adrian Gropper -
Alec Laws -
David Chadwick