Difference between revisions of "Purpose for Access Request"

From MgmtWiki
Jump to: navigation, search
m (→‎References)
(→‎Current Standard Request Messages)
 
Line 32: Line 32:
 
  user ==> responds with signed consent to rp winch MUST include All required purposes plus opt-in optional purposes
 
  user ==> responds with signed consent to rp winch MUST include All required purposes plus opt-in optional purposes
 
  user <==  rp response with ANCR signed by data controller (who may not be the rp)
 
  user <==  rp response with ANCR signed by data controller (who may not be the rp)
 +
 +
==Use Cases==
 +
===Ladies' Night at the Bar===
 +
test use case worked out in the PEMC environment.
 +
 +
* A bar offers a 50% discount on ladies' night to gender females.
 +
* The bar does not want the liability of determining the genders
 +
 +
The bar MUST verify age or lose its license. This includes a visual check of the holder's facial image.
 +
The bar decided to request gender from the driver's license.
 +
This use case works fine for ISO 13018-1, and so I posit it should work fine for 13018-5.
 +
The advantage to the holder of a -5 is that the holder gets to choose if the gender element is released.
 +
As AAMVA points out, the holder is under no obligation to provide any information from the -5.
 +
So here is the UX solution I propose.
 +
# Data "ageover21" is required. (Purpose is state regulation of access)
 +
# Facial Image is required but not retained. (purpose is state regulation of access and local reader capability)
 +
# Data "gender" is optional. (purpose is access to low priced drinks.)
 +
The result of the driver's license is the issuance of a token in the form of a wrist band.
 +
# Yellow to access the bar
 +
# Pink to access the bar and low-cost drinks.
  
 
==Current Standard Request Messages==
 
==Current Standard Request Messages==

Latest revision as of 09:27, 26 August 2022

Full Title

This is a discussion of the purpose for which a Relying Party or Verifier is requesting User Private Information.

Context

There are two environments where this is designed to work.

  1. user's computer attached to the internet.
  2. user's handheld mobile device.

The goal of this discussion is the creation of a display to the holder of a request for some details needed to create a transaction between the holder and the Verifier.

  • The request must reflect:
  1. The sort of transaction for which data is required.
  2. Any information required to complete the transaction and whether it is to be retained by the verifier.
  3. Any optional information that the verifier wishes that is not required by the immediate transaction.
  1. Display the information to the holder in a language that the user can understand.
  2. Input the holder's response

Taxonomy

  • Trust Authority (governance, vocabularies, etc.)
  • Holder - will typically be the subject of the data aka user
  • User
    • User Device (may provide proof of presence)
    • User Agent application
  • RP
    • reader
    • verifier
    • data controller
    • data processor

Data Flows

user ==>  rp web site where user clicked something that needs data
user <==  rp sends OAUTH 2 request with the purpose for which data is needed
user ==> responds with signed consent to rp winch MUST include All required purposes plus opt-in optional purposes
user <==  rp response with ANCR signed by data controller (who may not be the rp)

Use Cases

Ladies' Night at the Bar

test use case worked out in the PEMC environment.

  • A bar offers a 50% discount on ladies' night to gender females.
  • The bar does not want the liability of determining the genders

The bar MUST verify age or lose its license. This includes a visual check of the holder's facial image. The bar decided to request gender from the driver's license. This use case works fine for ISO 13018-1, and so I posit it should work fine for 13018-5. The advantage to the holder of a -5 is that the holder gets to choose if the gender element is released. As AAMVA points out, the holder is under no obligation to provide any information from the -5. So here is the UX solution I propose.

  1. Data "ageover21" is required. (Purpose is state regulation of access)
  2. Facial Image is required but not retained. (purpose is state regulation of access and local reader capability)
  3. Data "gender" is optional. (purpose is access to low priced drinks.)

The result of the driver's license is the issuance of a token in the form of a wrist band.

  1. Yellow to access the bar
  2. Pink to access the bar and low-cost drinks.

Current Standard Request Messages

The standards all call these Authorization Requests rather than Access Requests, which is the typical current transaction type and the only one addressed here.

OAUTH Authorization Request

From RFC 6749 OAuth 2.0 October 2012

The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI using the "application/x-www-form-urlencoded" format. 

response_type
REQUIRED.  Value MUST be set to "code".

client_id
REQUIRED.  The client identifier as described in Section 2.2.

redirect_uri
OPTIONAL.  As described in Section 3.1.2.

scope
OPTIONAL.  The scope of the access request as described by   Section 3.3.
(n.b. The scope could imply a purpose or be repurposed to do so.)

state
RECOMMENDED.  An opaque value used by the client to maintain state between the request and callback.  The authorization server includes this value when redirecting the user-agent back to the client.  The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12.

For example, the parameters "response_type", "client_id", "state", and "redirect_uri" are encoded in the URI of the request:
 GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

JAR

The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request IETF RFC 9101 (2021-08-21)]
The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through User Agents such as web Browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained.

PAR

OAuth 2.0 Pushed Authorization Requests 2021-09 IETF RFC 9126
This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint.

RAR

OAuth 2.0 Rich Authorization Requests draft-ietf-oauth-rar-12 2022-05-05
This document specifies a new parameter "authorization details" that is used to carry fine-grained authorization data in OAuth messages.

W3C Data Privacy Vocabulary

  • Collected sources
  • Data elements defined in the DPV
  • EU SPECIAL Project (Scalable Policy-aware Linked Data Architecture For Privacy, Transparency and Compliance) ran from 2017 to 2019, now dormant.
    • supports the acquisition of user consent at collection time and the recording of both data and metadata (consent policies, event data, context) according to legislative and user-specified policies,
    • caters for privacy-aware, secure workflows that include usage/access control, transparency and compliance verification,
    • demonstrates robustness in terms of performance, scalability and security, all of which are necessary to support privacy preserving innovation in Big Data environments. and
    • provides a dashboard with feedback and control features that make privacy in Big Data comprehensible and manageable for data subjects, controllers, and processors.

Normative Specification

  • The Purpose MUST be included in all requests for User Information (aka PII). The schema for the Purpose SHOULD be included in a @context element as a URL to the appropriate schema.
  • The Purpose MUST include an indication if it is REQUIRED, otherwise it will be considered to be an OPT-IN request.
  • If the user does not respond to all required requests, the verifier SHOULD reject the response.

Non-normative Information

Example Schema

{
  "@context": {
    "@version": 1.0,
    "@protected": true,

<== other content of the document inserted here ==>

    "Purpose": {
      "@id": "https://www.w3.org/2018/consents#consent",
      "@context": {
        "@version": 1.0,
        "@protected": true,

        "id": "@id",
        "type": "@type",

        "consent": "https://www.w3.org/20xx/consent#",
        "xsd": "http://www.w3.org/2001/XMLSchema#",

        "consentSchema": {
          "@id": "consent:consentSchema",
          "@type": "@id",
          "@context": {
            "@version": 1.0,
            "@protected": true,

            "id": "@id",
            "type": "@type",

            "consent": "https://www.w3.org/20xx/consents#",

            "JsonSchemaValidator2018": "consent:JsonSchemaValidator2018"
          }
        },
        [
          {
          "consentPurpose": {"@id": "consent:consentPurpose", "@type": "@id"},
          "consentRequired": {"@id": "consent:consentRequired", "@type": "@id"},
          "evidence": {"@id": "consent:evidence", "@type": "@id"},
          "expirationDate": {"@id": "consent:expirationDate", "@type": "xsd:dateTime"},
          "issuanceDate": {"@id": "consent:issuanceDate", "@type": "xsd:dateTime"},
          "refreshService": {
            "@id": "consent:refreshService",
            "@type": "@id",
            "@context": {
              "@version": 1.1,
              "@protected": true,

              "id": "@id",
              "type": "@type",

              "consent": "https://www.w3.org/20xx/consent#",

              "ManualRefreshService2018": "consent:ManualRefreshService2018"
            }
          }
        }
       ]
      },
          "termsOfUse": {"@id": "consent:termsOfUse", "@type": "@id"},
          "validFrom": {"@id": "consent:validFrom", "@type": "xsd:dateTime"},
          "validUntil": {"@id": "consent:validUntil", "@type": "xsd:dateTime"}
    },
    "Consent" {
      -- all of the elements for consent defined here
    }
  }
}

References

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Purpose_for_Access_Request&oldid=15543"