Consent Grant: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
(Created page with "==Full Title or Meme== Consent Grant is a token niblet that can be passed from a user to a web site as proof of granting consent. ==Context== * The wiki page is focused o...")
 
Line 14: Line 14:


==Solutions==
==Solutions==
* For this wiki the solution will be some sort of digital token that identifies the subject and is signed by the subject private key.
* 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 in json + jose({header}.{body}.{signature}) format that are included in the token.
* 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 access token that is sent to a relying party by the user; and then on to the resource server.
* 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.


{|border="1" padding="2" width="799px"
{|border="1" padding="2" width="799px"

Revision as of 16:20, 25 July 2020

Full Title or Meme

Consent Grant is a token niblet that can be passed from a user to a web site as proof of granting consent.

Context

  • The wiki page is focused on the need for a user on the web to give some other party the ability to acquire access to their personal attributes.
  • Some examples of Consent Grant include:

Use Cases

  • TK

Actors

  • A valuable Resource that is hosted on a Resource Server (RS). (Typically data, but it could also be a service API.)
  • The Relying Party (RP) that requests access to the Resource from the user.

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
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 structure limits the scope of the grant MAY
jwk key of the sub (the signer) include by value or by ref MAY
signature JWS created by the sub's key 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.

References