Difference between revisions of "Purpose for Access Request"
(→Current Standard Request Messages)
(→OAUTH Authorization Request)
|Line 25:||Line 25:|
REQUIRED. Value MUST be set to "code".
REQUIRED. The client identifier as described in Section 2.2.
OPTIONAL. As described in Section 3.1.2.
OPTIONAL. The scope of the access request as described by Section 3.3.
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.
Revision as of 09:46, 5 August 2022
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:
- The sort of transaction for which data is required.
- Any information required to complete the transaction and whether it is to be retained by the verifier.
- Any optional information that the verifier wishes that is not required by the immediate transaction.
- It is the responsibility of the User Agent to:
- Display the information to the holder in a language that the user can understand.
- Input the holder's response
- User Agent
Current Standard Request Messages
These are all call Authorization Requests rather than Access Requests, which is the typical current transaction type.
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.
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.
JARThe OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request IETF RFC 9102(2021-08-21]
PAROAuth 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.
RAROAuth 2.0 Rich Authorization Requests draft-ietf-oauth-rar-12 2022-05-05
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.
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.