Internet-Draft | DR+ Action: Sharing Arrangement V1 | August 2023 |
Low & Kolera | Expires 2 February 2024 | [Page] |
Describes the CDR Sharing Arrangement V1¶
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 2 February 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This specification uses the terms "Consumer", "Data Holder", "Data Recipient", "Personally Identifiable Information (PII)", "Pairwise Pseudonymous Identifier (PPID)", "Software Product" as defined by [CDRPLUS-INFOSEC-BASELINE].¶
CDR Sharing Arrangement CDR Sharing Arrangement Identifier Once Off Authorisation¶
The following provisions apply to participants considered a Data Holder.¶
The Holder CDR Arrangement (HCARE) Revocation endpoint accepts a CDR Arrangement Identifier and immediately revokes the CDR Sharing Arrangement.¶
The HCARE endpoint MUST be advertised using the cdr_arrangement_revocation_endpoint
attribute at the OpenID Connect Discovery 1.0 [OIDC-Discovery] endpoint.¶
The HCARE endpoint receives requests using the HTTP POST [RFC7231] method with parameters sent as application/x-www-form-urlencoded
data as defined in [W3C.REC-html5-20141028].¶
In addition to authentication credentials described in Section 2.2 of [RFC7523] the endpoint includes the CDR Arrangement Identifier as an additional parameter, specified as follows:¶
cdr_arrangement_id
: REQUIRED The CDR Arrangement Identifier previously provided in the token and introspection endpoint responses.¶
An example request to the Holder CDR Arrangement Revocation Endpoint is as follows:¶
POST https://data.holder.com.au/arrangements/revoke HTTP/1.1 Host: data.holder.com.au Content-Type: application/x-www-form-urlencoded client_id=s6BhdRkqt3& client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer& client_assertion=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyNDU2In0.ey ...& cdr_arrangement_id=5a1bf696-ee03-408b-b315-97955415d1f0¶
The authorisation server:¶
cdr_arrangement_id
relates to a valid CDR Sharing Arrangement and;¶
cdr_arrangement_id
belongs to validated client¶
If all of the above conditions are met the authorisation server:¶
In the event of a successful revocation, the authorisation server:¶
In the event of a failure to validate the CDR Arrangement conditions the authorisation server:¶
Retry-After
indicating the earliest retry time¶
The following additional error code is defined for the HCARE endpoint:¶
Code | Description | Error Detail |
---|---|---|
urn:au-cds:error:cds-all:Authorisation/InvalidArrangement
|
The arrangement could not be found. | The provided cdr_arrangement_id value |
The following provisions apply to participants operating individual Software Products.¶
The Recipient CDR Arrangement (RCARE) Revocation endpoint is a CDR specific endpoint that accepts a CDR Arrangement Identifier and immediately revokes the CDR Sharing Arrangement.¶
The protected resource calls the RCARE endpoint using an HTTP POST [RFC7231] request with parameters sent as application/x-www-form-urlencoded
data as defined in [W3C.REC-html5-20141028].¶
cdr_arrangement_jwt
REQUIRED. A single signed [JWT] containing the following parameters:¶
cdr_arrangement_id
representing the CDR Arrangement Identifier previously provided in the token and introspection endpoint responses;¶
iss
: The Holder Brand ID as per Section X.X in [CDRPLUS-ADMISSION-CONTROL]¶
sub
: The Holder Brand ID as per Section X.X in [CDRPLUS-ADMISSION-CONTROL]¶
aud
: The URI to the RCARE Endpoint as per Section X.X in [CDRPLUS-ADMISSION-CONTROL]¶
jti
: A unique identifier for the token¶
exp
: Expiration time on or after the JWT must not be accepted¶
In addition, the client includes an Authorization
header parameter with a Bearer token containing a single signed [JWT] with the following parameters:¶
iss
: The Holder Brand ID as per Section X.X in [CDRPLUS-ADMISSION-CONTROL]¶
sub
: The Holder Brand ID as per Section X.X in [CDRPLUS-ADMISSION-CONTROL]¶
aud
: The URI to the RCARE Endpoint as per Section X.X in [CDRPLUS-ADMISSION-CONTROL]¶
jti
: A unique identifier for the token¶
exp
: Expiration time on or after the JWT must not be accepted¶
For example, a Holder may request CDR Arrangement revocation with the following request:¶
POST https://data.recipient.com.au/arrangements/revoke HTTP/1.1 Host: data.recipient.com.au Content-Type: application/x-www-form-urlencoded Authorization: Bearer eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyNDU2In0.ey … cdr_arrangement_jwt=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyNDU2In0.ey ...&¶
The Recipient first validates the Holder credentials and then verifies whether the CDR Arrangement Identifier exists and was issued by the Holder making the CDR Arrangement Revocation request. If this validation fails, the request is refused and the Holder is informed of the error by the RCARE endpoint as described below.¶
In the next step, the Recipient invalidates the CDR Arrangement and SHOULD discard associated tokens. Data Minimisation events SHOULD also be triggered on receipt of this event.¶
The HCARE endpoint receives requests using the HTTP POST [RFC7231] method with parameters sent as application/x-www-form-urlencoded
data as defined in [W3C.REC-html5-20141028].¶
In addition to authentication credentials described in Section 2.2 of [RFC7523] the endpoint includes the CDR Arrangement Identifier as an additional parameter, specified as follows:¶
cdr_arrangement_id
: REQUIRED The CDR Arrangement Identifier previously provided in the token and introspection endpoint responses.¶
An example request to the Holder CDR Arrangement Revocation Endpoint is as follows:¶
POST https://data.holder.com.au/arrangements/revoke HTTP/1.1 Host: data.holder.com.au Content-Type: application/x-www-form-urlencoded client_id=s6BhdRkqt3& client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer& client_assertion=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyNDU2In0.ey ...& cdr_arrangement_id=5a1bf696-ee03-408b-b315-97955415d1f0¶
The authorisation server:¶
cdr_arrangement_id
relates to a valid CDR Sharing Arrangement¶
cdr_arrangement_id
belongs to the client validated by (1)¶
If all of the above conditions are met the authorisation server:¶
In the event of a successful revocation, the RCARE:¶
In the event of a failure to validate the CDR Arrangement conditions the authorisation server:¶
Retry-After
indicating the earliest retry time¶
The following additional error code is defined for the HCARE endpoint:¶
Code | Description | Error Detail |
---|---|---|
urn:au-cds:error:cds-all:Authorisation/InvalidArrangement
|
The arrangement could not be found. | The provided cdr_arrangement_id value |