Delegation: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
 
(34 intermediate revisions by the same user not shown)
Line 3: Line 3:


==Context==
==Context==
* There appear to be two distinct types of delegation. This page will focus on the first. [https://news.uga.edu/people-may-trust-computers-more-than-humans/ Although it should be noted that it is getting to the point that people are becoming more likely to trust a computer than a human.]
# Delegation from one human to another, whether it is a family member, a lawyer or a physician.
# Delegation from one human to some system, which used to be a organization, but lately is some user agent or AI.
* The wiki page is focused on the need for a digital entity on the web to give some other party the ability to exercise some of the capability to some other digital entity.
* The wiki page is focused on the need for a digital entity on the web to give some other party the ability to exercise some of the capability to some other digital entity.
* In other words, a delegation is a binding between an end user and a role that comes with specific privileges. (aka role based authorization)
* In the case of human users of the web they will have a [[User Agent]] through which they can express their intents on the web.
* In the case of human users of the web they will have a [[User Agent]] through which they can express their intents on the web.
* Alternate terms are listed on the wiki page for [[Guardian]].
* Some examples of delegation include:
* Some examples of delegation include:
** A manager goes on vacation and provides a temporary replacement with the ability to control access to the division web site repository.
** A manager goes on vacation and provides a temporary replacement with the ability to control access to the division web site repository.
Line 12: Line 17:
** A husband and wife grant each other authority to make medical decisions for the other with a defined set of limitations.
** A husband and wife grant each other authority to make medical decisions for the other with a defined set of limitations.
** I add medical conditions to my smartphone so that any authorized EMT can view them if i am found comatose. (Here the delegation is to a situational role.)
** I add medical conditions to my smartphone so that any authorized EMT can view them if i am found comatose. (Here the delegation is to a situational role.)
** I allow my smartphone to track my contacts for release by public health order.
** I want to assert that the name subject is a covered dependent for purposes of insurance or other coverage.
===Use Cases===
===Use Cases===
* [[Delegate Credentials Use Case]]
* [[Delegate Credentials Use Case]]
Line 19: Line 26:


===Actors===
===Actors===
* A valuable Resource that is hosted on a Resource Server (RS). (Typically data, but it could also be a service API.)
# A valuable Resource that is hosted on a Resource Server (RS). (Typically data, but it could also be a service API.)
* The Resource Owner (RO) that controls access to the Resource.
# The Resource Owner (RO) that controls access to the Resource.
* The user of the Resource that receives the delegation token from the Resource Owner.
# The user of the Resource that receives the delegation token from the Resource Owner.
* The Relying Party (RP) that requests access to the Resource from the user.
# The Relying Party (RP) that requests access to the Resource from the user.
 
Check out sync with HEART https://openid.net/wg/heart/  for applicable use case
* https://openid.net/wordpress-content/uploads/2018/07/Emerging-Standards-in-Healthcare-Identiverse-2018-06-27-rev-2.pdf


==Solutions==
==Solutions==
Line 40: Line 50:
|user || Identifier of the recipient of this grant || Must be link to a signing key||MUST
|user || Identifier of the recipient of this grant || Must be link to a signing key||MUST
|-
|-
|relation ||of user to subject || array; parant; guardian; spouse; u13; emancipated; legal||MAY
|Consent ID || Id of this consent || may be just a nonce, but intent is uniqueness || May
|-
|relation ||of user to subject - array||parent; guardian; spouse; u13; minor; public; legal||MAY
|-
|-
|aud || Identifier of the resource server || Must be link to a decryption key||MUST
|aud || Identifier of the resource server || Must be link to a decryption key||MUST
Line 46: Line 58:
|scope|| Identifier of the resource to be shared|| array||MAY
|scope|| Identifier of the resource to be shared|| array||MAY
|-
|-
|stipulation || structure||limits the scope of the grant ||MAY
|stipulation || json structure TDB||limits the scope of the grant ||MAY
|-
|-
|exp || Unix epoch date||when delegation expires ||MAY
|exp || Unix epoch date||when delegation expires ||MAY
|-
|event || external condition that enables or expands grant||TBD ||MAY
|-
| trust_federation || a source of rules to evaluate|| array eg HIPAA, GDPR ||MAY
|-
|-
|jwk || key of the sub (the signer)||include by value or by ref ||MAY
|jwk || key of the sub (the signer)||include by value or by ref ||MAY
|-
|-
|signature || JWS|| created by the sub's key||MUST
|authority || Id of the signer || only applies if guardianship. || MAY
|-
|signature || JWS|| created by the sub's key (authority for guardianship)||MUST
|-
|-
|}
|}
*If a puid is used, there must be some mechanism to bind the puid to the sub that is outside the scope of this document. That mechanism will need to handle the recovery of access where the sub's authenticator cannot be used for any reason.
*If a puid is used, there must be some mechanism to bind the puid to the sub that is outside the scope of this document. That mechanism will need to handle the recovery of access where the sub's authenticator cannot be used for any reason.
* Relationship is designed to show access rights of user over subject data. e.g. guardian of the person is a legal authority, u13 means the subject is a child under the age of 13, both of these gives the legal authority. If the element is absent, the assumption must be that this is a pure delegation between consenting adults.
* Relationship is designed to show access rights of user over subject data. e.g. guardian of the person is a legal authority, u13 means the subject is a child under the age of 13, both of these gives the legal authority and so consent of the subject is not required. Minor means that the subject has not been emancipated but has some right over their own data. Public means that a public emergency rule has been applied by a legal process. Legal typically means that a probate judge has issues a guardianship order. If the element is absent (or designated as "none"), the assumption must be that this is a pure delegation between consenting adults. This is not intended to describe familial relationships.
* Scope may be a purpose, for example, data is needed to fulfil the purposes of a prescribing physician.
* Scope may be a purpose, for example, data is needed to fulfill the purposes of a prescribing physician. Such detailed scope are likely to depend on the trust_federation
* Stipulated access to information is complex and out-of-scope for the current version.
 
==Requirements==
*Expiration and relationship are required for U13 and possibly for minor or not emancipated (which includes humans that were never able to become independent.)


==References==
==References==
* See also the wiki page on [[Consent Grant]].
* See also the wiki page on [[Consent Grant]].
* See Appendix C of [https://sovrin.org/wp-content/uploads/Sovrin-Glossary-V3.pdf Sovrin Glossary V3] for a Self-sovereign version of Delegates, Guardians, and Controllers. <blockquote>Delegation is perhaps the most common of all identity control relationships. People constantly delegate responsibilities to other people; organizational structures exist largely to define delegation relationships. The key to defining Delegation in the Sovrin ecosystem is that it exists only between two Independent Identity Owners who both have direct control of their Private Keys. If one Identity Owner does not control their Private Keys, it requires Guardianship; if one of the Entities is a Thing, it requires a Controller</blockquote>

Latest revision as of 21:03, 15 April 2021

Full Title or Meme

Delegation allows the owner of access to a resource to give some subset of that ability to another party.

Context

  1. Delegation from one human to another, whether it is a family member, a lawyer or a physician.
  2. Delegation from one human to some system, which used to be a organization, but lately is some user agent or AI.
  • The wiki page is focused on the need for a digital entity on the web to give some other party the ability to exercise some of the capability to some other digital entity.
  • In other words, a delegation is a binding between an end user and a role that comes with specific privileges. (aka role based authorization)
  • In the case of human users of the web they will have a User Agent through which they can express their intents on the web.
  • Alternate terms are listed on the wiki page for Guardian.
  • Some examples of delegation include:
    • A manager goes on vacation and provides a temporary replacement with the ability to control access to the division web site repository.
    • A person is declared unfit to manage their affairs by a court of competent jurisdiction and a guardian is appointed.
    • A parent and a child have the reversed case where the parent gives the child some ability to visit web sites that have age restrictions.
    • The president of the United States goes into surgery and passes control of the nuclear deterrent to the vice president.
    • A husband and wife grant each other authority to make medical decisions for the other with a defined set of limitations.
    • I add medical conditions to my smartphone so that any authorized EMT can view them if i am found comatose. (Here the delegation is to a situational role.)
    • I allow my smartphone to track my contacts for release by public health order.
    • I want to assert that the name subject is a covered dependent for purposes of insurance or other coverage.

Use Cases

Actors

  1. A valuable Resource that is hosted on a Resource Server (RS). (Typically data, but it could also be a service API.)
  2. The Resource Owner (RO) that controls access to the Resource.
  3. The user of the Resource that receives the delegation token from the Resource Owner.
  4. The Relying Party (RP) that requests access to the Resource from the user.

Check out sync with HEART https://openid.net/wg/heart/ for applicable use case

Solutions

  • For this wiki the solution will be some sort of digital token niblet that identifies the subject and is signed by the subject private key.
  • The follows shows the elements of the niblet in json + jose({header}.{body}.{signature}) format that are included in the token.
  • The best practice for this token is to send it as a signed, but not encrypted jose formatted string with a JWS signature. This will allow the token to be embedded in the grant that is sent to a relying party by the user; and then on to the resource server.
Element Name Contents Explanation for category Cat
header key info required to validate the signature MUST
sub identifier of the RO the grantor of access MUST
puid Persistent Identifier of RO to handle recovery operation MAY
user Identifier of the recipient of this grant Must be link to a signing key MUST
Consent ID Id of this consent may be just a nonce, but intent is uniqueness May
relation of user to subject - array parent; guardian; spouse; u13; minor; public; legal MAY
aud Identifier of the resource server Must be link to a decryption key MUST
scope Identifier of the resource to be shared array MAY
stipulation json structure TDB limits the scope of the grant MAY
exp Unix epoch date when delegation expires MAY
event external condition that enables or expands grant TBD MAY
trust_federation a source of rules to evaluate array eg HIPAA, GDPR MAY
jwk key of the sub (the signer) include by value or by ref MAY
authority Id of the signer only applies if guardianship. MAY
signature JWS created by the sub's key (authority for guardianship) MUST
  • If a puid is used, there must be some mechanism to bind the puid to the sub that is outside the scope of this document. That mechanism will need to handle the recovery of access where the sub's authenticator cannot be used for any reason.
  • Relationship is designed to show access rights of user over subject data. e.g. guardian of the person is a legal authority, u13 means the subject is a child under the age of 13, both of these gives the legal authority and so consent of the subject is not required. Minor means that the subject has not been emancipated but has some right over their own data. Public means that a public emergency rule has been applied by a legal process. Legal typically means that a probate judge has issues a guardianship order. If the element is absent (or designated as "none"), the assumption must be that this is a pure delegation between consenting adults. This is not intended to describe familial relationships.
  • Scope may be a purpose, for example, data is needed to fulfill the purposes of a prescribing physician. Such detailed scope are likely to depend on the trust_federation
  • Stipulated access to information is complex and out-of-scope for the current version.

Requirements

  • Expiration and relationship are required for U13 and possibly for minor or not emancipated (which includes humans that were never able to become independent.)

References

  • See also the wiki page on Consent Grant.
  • See Appendix C of Sovrin Glossary V3 for a Self-sovereign version of Delegates, Guardians, and Controllers.

    Delegation is perhaps the most common of all identity control relationships. People constantly delegate responsibilities to other people; organizational structures exist largely to define delegation relationships. The key to defining Delegation in the Sovrin ecosystem is that it exists only between two Independent Identity Owners who both have direct control of their Private Keys. If one Identity Owner does not control their Private Keys, it requires Guardianship; if one of the Entities is a Thing, it requires a Controller