From 739b0734e49f54d6ff4aeb734bd9462cbe8bdc0a Mon Sep 17 00:00:00 2001 From: James Bligh Date: Sat, 18 Apr 2020 19:43:07 +1000 Subject: [PATCH] Fixes based on team review --- .../releasenotes/releasenotes.1.3.0.html | 5 + docs/index.html | 94 ++++++++++--------- slate/source/includes/_security.md.erb | 18 ++-- .../releasenotes/releasenotes.1.3.0.html.md | 1 + .../source/includes/standards/_principles.md | 1 + 5 files changed, 69 insertions(+), 50 deletions(-) diff --git a/docs/includes/releasenotes/releasenotes.1.3.0.html b/docs/includes/releasenotes/releasenotes.1.3.0.html index d57b9f85..a893c129 100644 --- a/docs/includes/releasenotes/releasenotes.1.3.0.html +++ b/docs/includes/releasenotes/releasenotes.1.3.0.html @@ -325,6 +325,11 @@

Information Security Profile

Addition of changes arising from the concurrent consent consultation. This resulted in a number of changes to the Information Security profile General + +MTLS RFC +The reference to the MTLS normative reference has been updated from the draft to the final standard +Normative References +

Consumer Experience

diff --git a/docs/index.html b/docs/index.html index b864c748..86363e70 100644 --- a/docs/index.html +++ b/docs/index.html @@ -905,13 +905,16 @@

CX Principle 2: The

CX Principle 3: The CDR is Comprehensible

-

When interacting with the CDR, consumers are able to understand the following: -* who their data is shared with; -* what information is shared; -* when sharing begins and ceases; -* where data is shared to and from; -* why their data is being requested; and -* how they can manage and control the sharing and use of their data.

+

When interacting with the CDR, consumers are able to understand the following:

+ +

CX Principle 4: The CDR is Simple and Empowering

@@ -1793,6 +1796,7 @@

Symbols and Abbreviated terms

  • LoAs: Levels of Assurance
  • MTLS: Mutually Authenticated Transport Layer Security
  • OIDC: Open ID Connect
    • +
  • PAR: Pushed Authorisation Requests
  • PI: Personal Information
  • PKI: Public Key Infrastructure
  • PPID: Pairwise Pseudonymous Identifier
    • @@ -1874,7 +1878,7 @@

    OIDC Hybrid Flow

    Only a response_type (see section 3 of [OIDC]) of code id_token SHALL be allowed.

    -

    The request_uri parameter SHALL NOT be supported.

    +

    The request_uri parameter is only supported if the Data Holder supports PAR.

    In addition, the following statements are applicable for this flow:

    @@ -2152,8 +2156,6 @@

    Refresh Token

    Refresh Token expiration MAY be any length of time greater than 28 days but MUST NOT exceed the end of the duration of sharing consented to by the Consumer.

    Data Holders MAY cycle Refresh Tokens when an Access Token is issued. If Refresh Token cycling is not performed then the Refresh Token MUST NOT expire before the expiration of the sharing consented by the Customer.

    - -

    The revocation or expiration of the currently active refresh token should be understood to effectively revoke or expire the sharing arrangement as a whole.

    Token Expiry

    The expiry time for issued access tokens and refresh tokens must be deterministic for the Data Recipient.

    @@ -2496,9 +2498,12 @@

    OpenID Provider Configuration E
  • id_token_encryption_enc_values_supported: The list of the supported JWE encryption methods for securing the issued ID tokens.
    • -

    From November 2020, the Data Holder metadata MUST include: -- cdr_arrangement_endpoint: URL of the CDR Arrangement End Point for consent revocation. -- pushed_authorization_request_endpoint: URL of the Pushed Authorisation End Point used to support [PAR].

    +

    From November 2020, the Data Holder metadata MUST include:

    + +

    Authorisation End Point

    @@ -2731,10 +2736,10 @@

    Revocation End Point

    CDR Arrangement Management End Point

    Non-Normative Example

    -
    -
    ## Request
 
-DELETE https://data.holder.com.au/arrangements/5a1bf696-ee03-408b-b315-97955415d1f0
+
    Request
    
+
+
    DELETE https://data.holder.com.au/arrangements/5a1bf696-ee03-408b-b315-97955415d1f0
 HTTP/1.1
 Host: data.holder.com.au
 Authorization: Bearer eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyNDU2In0.ey...
@@ -2769,18 +2774,21 @@ 
    CDR Arrangement Management End Poi
 
 
    From November 2020, Data Holders and Data Recipients MUST implement an arrangement management end point that can be used to revoke an existing sharing arranagement.
    
 
-
    This end point will be implemented according to the following:
-* Consent management MUST be managed through the new CDR Arrangement Management API. The CDR Arrangement Management API only supports DELETE for revocation of consent for the scope of concurrent consent.
-* Data Recipients and Data Holders MUST revoke consent by calling the CDR Arrangement Management API with a valid CDR Arrangement Identifier
-* Data Holders MUST publish their CDR Arrangement Management API using their OpenID Provider Metadata discovery endpoint
-* Data Recipients MUST expose their CDR Arrangement Management API under their Recipient Base URI published in their Software Statement Assertion
-* If the CDR Arrangement Management API is called for revocation, it MUST delete associated refresh and/or access tokens
-* For Data Holders, Data Recipients must be authenticated when they call this end point using a valid Access Token as specified in section 10.3 of [OAUTH2]
-* For Data Holders, if the cdr_arrangement_id is not related to the consumer identified by the Access Token provided it MUST be rejected
-* For Data Recipients, Data Holder must be authenticated when they call this end point according to the guidance in the Client Authentication section.
-* For Data Recipients, if the cdr_arrangement_id is not related to the Data Holder making the call it MUST be rejected
-* A call to this end point should be responded to with HTTP status code 204 if the sharing arrangement has been revoked successfully
-* A call to this end point should be responded to with HTTP status code 422 if the client submitted an invalid identifier
    
+
    This end point will be implemented according to the following:
    
+
+
      
+
    • Consent management MUST be managed through the new CDR Arrangement Management API. The CDR Arrangement Management API only supports DELETE for revocation of consent for the scope of concurrent consent.
      • 
+
    • Data Recipients and Data Holders MUST revoke consent by calling the CDR Arrangement Management API with a valid CDR Arrangement Identifier
      • 
+
    • Data Holders MUST publish their CDR Arrangement Management API using their OpenID Provider Metadata discovery endpoint
      • 
+
    • Data Recipients MUST expose their CDR Arrangement Management API under their Recipient Base URI published in their Software Statement Assertion
      • 
+
    • If the CDR Arrangement Management API is called for revocation, it MUST delete associated refresh and/or access tokens
      • 
+
    • For Data Holders, Data Recipients must be authenticated when they call this end point using a valid Access Token as specified in section 10.3 of [OAUTH2]
      • 
+
    • For Data Holders, if the cdr_arrangement_id is not related to the consumer identified by the Access Token provided it MUST be rejected
      • 
+
    • For Data Recipients, Data Holder must be authenticated when they call this end point according to the guidance in the Client Authentication section.
      • 
+
    • For Data Recipients, if the cdr_arrangement_id is not related to the Data Holder making the call it MUST be rejected
      • 
+
    • A call to this end point should be responded to with HTTP status code 204 if the sharing arrangement has been revoked successfully
      • 
+
    • A call to this end point should be responded to with HTTP status code 422 if the client submitted an invalid identifier
      • 
+
    
 
    
 
    Because single-consent sharing arrangements will be established before concurrent consent
 future dated obligations, there is the chance that a consumer may revoke consent with a
@@ -2809,11 +2817,10 @@ 
    Pushed Authorisation End Point
    
 
    Decoded Request
    
 
 
    {
-  "iss": "https://www.holder.com.au",
+  "iss": "https://data.holder.com.au",
   "aud": "a7AfcPcsl2",
   "exp": 1311281970,
   “client_id”: s6BhdRkqt3,
-  “grant_management_mode”: create,
   “response_type”: ”code id_token”,
   “client_id”: 12345,
   “redirect_uri”: ”https://www.recipient.com.au%2Fcoolstuff”,
@@ -2869,16 +2876,19 @@ 
    Pushed Authorisation End Point
    
 
 
    The Data Holder response provides the Data Recipient with a Request URI in the response. The Request URI is then passed to the Data Holder’s Authorisation endpoint to initiate an authorisation flow. In this way, the Data Recipient has staged their authorisation intent with the Data Holder and can then proceed via the backchannel.
    
 
-
    In addition:
-* Data Holders MUST support request objects sent by reference for Pushed Authorisation Requests
-* Request Object references SHALL NOT be supported in any mode of use other than Pushed Authorisation Requests (PAR). If a Data Holder does not support Pushed Authorisation Requests (PAR), it MUST NOT support Request Object references.
-* Data Holders MUST publish their support for PAR as per the specification using OAuth/OpenID Provider Metadata parameters in discovery responses
-* The Request URI MUST expire between 10 seconds and 90 seconds
-* Data Recipients MAY provide an existing cdr_arrangement_id claim in an authorisation request object to establish a new consent under an existing arrangement
-* Data Holders MUST revoke existing refresh tokens and access tokens when a cdr_arrangement_id is provided in the authorisation request object but ONLY after successful authorisation
-* Data Recipients MUST observe data deletion and de-identification requirements for revoked consent after successful authorisation
-* If the cdr_arrangement_id is not related to the consumer being authenticated it MUST be rejected
-* If the cdr_arrangement_id is not related to the Data Holder it MUST be rejected
    
+
    In addition:
    
+
+
      
+
    • Data Holders MUST support request objects sent by reference for Pushed Authorisation Requests
      • 
+
    • Request Object references SHALL NOT be supported in any mode of use other than Pushed Authorisation Requests (PAR). If a Data Holder does not support Pushed Authorisation Requests (PAR), it MUST NOT support Request Object references.
      • 
+
    • Data Holders MUST publish their support for PAR as per the specification using OAuth/OpenID Provider Metadata parameters in discovery responses
      • 
+
    • The Request URI MUST expire between 10 seconds and 90 seconds
      • 
+
    • Data Recipients MAY provide an existing cdr_arrangement_id claim in an authorisation request object to establish a new consent under an existing arrangement
      • 
+
    • Data Holders MUST revoke existing refresh tokens and access tokens when a cdr_arrangement_id is provided in the authorisation request object but ONLY after successful authorisation
      • 
+
    • Data Recipients MUST observe data deletion and de-identification requirements for revoked consent after successful authorisation
      • 
+
    • If the cdr_arrangement_id is not related to the consumer being authenticated it MUST be rejected
      • 
+
    • If the cdr_arrangement_id is not related to the Data Holder it MUST be rejected
      • 
+
    
 
    Normative References
    @@ -2929,8 +2939,8 @@

    Normative References

     - - + + diff --git a/slate/source/includes/_security.md.erb b/slate/source/includes/_security.md.erb index f11d5a04..a6ccb5af 100644 --- a/slate/source/includes/_security.md.erb +++ b/slate/source/includes/_security.md.erb @@ -30,6 +30,7 @@ For information on the specific normative references that underpin this profile - **LoAs:** Levels of Assurance - **MTLS:** Mutually Authenticated Transport Layer Security - **OIDC:** Open ID Connect +- **PAR:** Pushed Authorisation Requests - **PI:** Personal Information - **PKI:** Public Key Infrastructure - **PPID:** Pairwise Pseudonymous Identifier @@ -102,7 +103,7 @@ authorisation code flow detailed under **[OIDC]**. Only a `response_type` (see [section 3](https://openid.net/specs/openid-connect-core-1_0.html#Authentication) of **[OIDC]**) of `code id_token` SHALL be allowed. -The `request_uri` parameter SHALL NOT be supported. +The `request_uri` parameter is only supported if the Data Holder supports PAR. In addition, the following statements are applicable for this flow: @@ -378,8 +379,6 @@ Refresh Token expiration MAY be any length of time greater than 28 days but MUST Data Holders MAY cycle Refresh Tokens when an Access Token is issued. If Refresh Token cycling is not performed then the Refresh Token MUST NOT expire before the expiration of the sharing consented by the Customer. -The revocation or expiration of the currently active refresh token should be understood to effectively revoke or expire the sharing arrangement as a whole. - ### Token Expiry The expiry time for issued access tokens and refresh tokens must be deterministic for the Data Recipient. @@ -718,6 +717,7 @@ At a minimum, the Data Holder metadata MUST include: - `id_token_encryption_enc_values_supported`: The list of the supported JWE encryption methods for securing the issued ID tokens. **From November 2020**, the Data Holder metadata MUST include: + - `cdr_arrangement_endpoint`: URL of the CDR Arrangement End Point for consent revocation. - `pushed_authorization_request_endpoint`: URL of the Pushed Authorisation End Point used to support **[PAR]**. @@ -864,9 +864,9 @@ Revocation of Refresh Tokens and Access Tokens MUST be supported. > Non-Normative Example -``` -## Request +>Request +``` DELETE https://data.holder.com.au/arrangements/5a1bf696-ee03-408b-b315-97955415d1f0 HTTP/1.1 Host: data.holder.com.au @@ -887,6 +887,7 @@ Authorization: Bearer eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyNDU2In0.ey **From November 2020**, Data Holders and Data Recipients MUST implement an arrangement management end point that can be used to revoke an existing sharing arranagement. This end point will be implemented according to the following: + * Consent management MUST be managed through the new CDR Arrangement Management API. The CDR Arrangement Management API only supports DELETE for revocation of consent for the scope of concurrent consent. * Data Recipients and Data Holders MUST revoke consent by calling the CDR Arrangement Management API with a valid CDR Arrangement Identifier * Data Holders MUST publish their CDR Arrangement Management API using their OpenID Provider Metadata discovery endpoint @@ -900,6 +901,7 @@ This end point will be implemented according to the following: * A call to this end point should be responded to with HTTP status code 422 if the client submitted an invalid identifier ### Race conditions and handling consent revocation with Data Recipients + Because single-consent sharing arrangements will be established before concurrent consent future dated obligations, there is the chance that a consumer may revoke consent with a Data Holder before a Data Recipient has obtained a sharing ID. In this instance, a Data @@ -930,11 +932,10 @@ request=eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjEyMyJ9.ey... ``` { - "iss": "https://www.holder.com.au", + "iss": "https://data.holder.com.au", "aud": "a7AfcPcsl2", "exp": 1311281970, “client_id”: s6BhdRkqt3, - “grant_management_mode”: create, “response_type”: ”code id_token”, “client_id”: 12345, “redirect_uri”: ”https://www.recipient.com.au%2Fcoolstuff”, @@ -975,6 +976,7 @@ Data Recipients must send authorisation request objects by reference by calling The Data Holder response provides the Data Recipient with a Request URI in the response. The Request URI is then passed to the Data Holder’s Authorisation endpoint to initiate an authorisation flow. In this way, the Data Recipient has staged their authorisation intent with the Data Holder and can then proceed via the backchannel. In addition: + * Data Holders MUST support request objects sent by reference for Pushed Authorisation Requests * Request Object references SHALL NOT be supported in any mode of use other than Pushed Authorisation Requests (PAR). If a Data Holder does not support Pushed Authorisation Requests (PAR), it MUST NOT support Request Object references. * Data Holders MUST publish their support for PAR as per the specification using OAuth/OpenID Provider Metadata parameters in discovery responses @@ -997,7 +999,7 @@ In addition: | **[JWT]** | JSON Web Token (JWT): |May 2015 | **[JWS]** | JSON Web Signature (JWS): |Feb 2016 | **[JWE]** | JSON Web Encryption (JWE): |May 2015 -| **[MTLS]** | OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens: |Aug 2019 +| **[MTLS]** | OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens: |Feb 2020 | **[OAUTH2]** | The OAuth 2.0 Authorization Framework: |Oct 2012 | **[OIDC]** | OpenID Connect Core 1.0 incorporating errata set 1: |Nov 2014 | **[OIDD]** | OpenID Connect Discovery 1.0 incorporating errata set 1: |Nov 2014 diff --git a/slate/source/includes/releasenotes/releasenotes.1.3.0.html.md b/slate/source/includes/releasenotes/releasenotes.1.3.0.html.md index 581c5f63..ed8043a9 100644 --- a/slate/source/includes/releasenotes/releasenotes.1.3.0.html.md +++ b/slate/source/includes/releasenotes/releasenotes.1.3.0.html.md @@ -36,6 +36,7 @@ Release notes for version 1.3.0 of the [CDR Standards](../../index.html). |Request Object Sample|Clarifications of non-normative example for the Request Object|[Request Object](../../index.html#request-object)| |Client Authentication Sample|Addition of non-normative samples for the client authentication section|[Client Authentication](../../index.html#client-authentication)| |Concurrent Consent|Addition of changes arising from the concurrent consent consultation. This resulted in a number of changes to the Information Security profile|General| +|MTLS RFC|The reference to the MTLS normative reference has been updated from the draft to the final standard|[Normative References](../../index.html#/#normative-references)| ## Consumer Experience |Change|Description|Link| diff --git a/slate/source/includes/standards/_principles.md b/slate/source/includes/standards/_principles.md index 3cdb7ea6..3913fbb0 100644 --- a/slate/source/includes/standards/_principles.md +++ b/slate/source/includes/standards/_principles.md @@ -64,6 +64,7 @@ their background, situation, experience, or personal characteristics. ####CX Principle 3: The CDR is Comprehensible When interacting with the CDR, consumers are able to understand the following: + * ***who*** their data is shared with; * ***what*** information is shared; * ***when*** sharing begins and ceases;
    [MTLS]OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens: https://tools.ietf.org/html/draft-ietf-oauth-mtls-17Aug 2019OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens: https://tools.ietf.org/html/rfc8705Feb 2020
    [OAUTH2]