diff --git a/docs/includes/changelog b/docs/includes/changelog index 3862db14..f0abf3e1 100644 --- a/docs/includes/changelog +++ b/docs/includes/changelog @@ -10,6 +10,12 @@ +13/5/2019 +0.8.4 +InfoSec Update +Imported the InfoSec content without update for recent proposals + + 12/5/2019 0.8.3 Optionality Update diff --git a/docs/index.html b/docs/index.html index 661e7dd9..c8d50371 100644 --- a/docs/index.html +++ b/docs/index.html @@ -265,55 +265,46 @@ Overview
  • - 1. InfoSec Profile 0.2.0 + CDR Federation
  • - 2. Overview + Authentication Flows
  • - 3. CDR Federation + Client Authentication
  • - 4. Authentication Flows + OIDC Client Types
  • - 5. Client Authentication + Tokens
  • - 6. OIDC Client Types + Scopes and Claims
  • - 7. Tokens + Identifiers and Subject Types
  • - 8. Scopes and Claims + Levels of Assurance (LoAs)
  • - 9. Identifiers and Subject Types + Transaction Security
  • - 10. Levels of Assurance (LoAs) + Request Object
  • - 11. Transaction Security + Endpoints
  • - 12. Request Object + Consent
  • - 13. Endpoints + Normative References
  • - 14. Consent -
    • -
  • - 15. Normative References -
    • -
  • - 16. Informative References -
    • -
  • - 17. Appendix + Informative References
    • @@ -632,7 +623,7 @@

    Introduction

    Note that security standards are only partially represented in these standards as they are under development by the Information Security Working Group. More detail can found at the Information Security Profile working draft.

    Standards

    -

    These standards represent version 0.8.2 of the high level standards which will support the creation of version 1. See the versioning section for more information on how versions are managed in the standard.

    +

    These standards represent version 0.8.4 of the high level standards which will support the creation of version 1. See the versioning section for more information on how versions are managed in the standard.

    Note that, in this proposal, the key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC2119.

    @@ -1517,90 +1508,12 @@

    Extension Versioning

    An optional header x-<PID>-v will be supported for all end points that can be used by the data consumer to request a specific version of extension fields to include in the response. See the section on HTTP Headers for more information on the use of this header.

    Security Profile

    Overview

    -

    This Information Security profile has been developed as part of the introduction in Australia of the Consumer Data Right legislation to give Australians greater control over their data.

    - -

    The Consumer Data Right is intended to apply sector by sector across the whole economy, beginning in the banking, energy and telecommunications sectors. These standards have been developed to facilitate the Consumer Data Right by acting as a specific baseline for implementation.

    - -

    These standards are governed by the Consumer Data Standards team inside Data61. Data61 has been appointed as the interim standards body. The work of the team is overseen by Mr. Andrew Stevens as interim Chair, with industry and consumer advice provided by an Advisory Committee. Data61 works closely with the Australian Competition and Consumer Commission (ACCC) as lead regulator of the Consumer Data Right, supported by the Office of the Australian Information Commissioner (OAIC).

    - -

    Securing of the API end points defined by the standards will be accomplished through alignment with well defined industry protocols and security profiles. Context specific constraints are then applied to these profiles to provide implementation clarity or reduce risk.

    - -

    In particular the standards are aligned to the Financial API (FAPI) Read/Wite profile.

    - -

    Note that the FAPI Read/Write profile builds on the FAPI Read Only profile and implies alignment with the use of Open ID Connect.

    - -

    The FAPI Read/Write profile implies specific implementation decisions that are worthy of explicit statement. There are also some additional, specific constraints are applicable for implementations conforming to these standards:

    - - -

    1. InfoSec Profile 0.2.0

    - -

    1.1. History

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    AuthorDateVersionDescription
    LP22/11/20180.0.1Created
    LP30/11/20180.0.2Created
    LP10/12/20180.0.3Created
    LP20/12/20180.1.0Created
    LP07/01/20190.1.1Created
    BK06/05/20190.2.0Created
    +

    This information security profile will be built upon the foundations of the +Financial-grade API Read Write Profile [FAPI-RW], the Financial-grade API Client Initiated Backchannel Authentication Profile [FAPI-CIBA], and other standards relating to +Open ID Connect 1.0 [OIDC].

    -

    The detailed change log for this artifact is available here.

    -

    1.2. Symbols and Abbreviated terms

    +

    For information on the specific normative references that underpin this profile refer to the Normative References section.

    +

    Symbols and Abbreviated terms

    -

    1.3. Requirements Notation and Conventions

    -

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

    -

    2. Overview

    -

    This artifact details the Consumer Data Right [CDR] Information Security -Profile (CDR-SP). This profile will be built upon the foundations of the -Financial-grade API Read Write Profile [FAPI-RW], the Financial-grade API Client Initiated Backchannel Authentication Profile [FAPI-CIBA], and other standards relating to -Open ID Connect 1.0 [OIDC].

    - -

    Whilst this is a technical artifact, it is guided by the core principles that -have to led to the creation of the Consumer Data Right. These are:

    - - -

    3. CDR Federation

    +

    CDR Federation

    The CDR Federation will facilitate the secure exchange of consumer data and federation metadata between multiple system entities which will assume one or more of the following roles:

    @@ -1672,20 +1568,20 @@

    3. CDR Federation

    maintained by the Australian Competition and Consumer Commission (ACCC). -

    3.1. Data Holder

    +

    Data Holder

    The Data Holder (DH) is a system entity that authenticates a consumer (resource owner or user), as part of an authorisation process initiated by a Data Recipient, and issues an authorisation for that Data Recipient to access the consumer's data via published APIs.

    A Data Holder assumes the role of an [OIDC] OpenID Provider.

    -

    3.2. Data Recipient

    +

    Data Recipient

    A Data Recipient (DR) is system entity that is authorised by a Data Holder to access consumer resources (APIs). A Data Recipient MUST capture consumer consent prior to commencing an authorisation process with a Data Holder.

    A Data Recipient MUST be accredited in order to participate in the CDR Federation. Accreditation rules for Data Recipients are beyond the scope of this artifact.

    A Data Recipient assumes the role of an [OIDC] Relying Party (Client).

    -

    3.3. Registry

    +

    Registry

    @@ -1700,7 +1596,7 @@

    3.3. Registry

    A full description of the Registry is beyond the scope of this document.

    -

    4. Authentication Flows

    +

    Authentication Flows

    This profile supports the authentication flows specified by FAPI [FAPI]. These are:

    -

    4.1. OIDC Hybrid Flow

    +

    OIDC Hybrid Flow

    The [OIDC] Hybrid Flow is a type of redirection flow where the consumers user agent is redirected from a Data Recipient’s (Relying Party) web site to a Data Holder’s Authorisation endpoint in the context of an [OIDC] authentication @@ -1729,7 +1625,7 @@

    4.1. OIDC Hybrid Flow

    The request_uri parameter SHALL NOT be supported.

    -

    4.2. Client-Initiated Backchannel Authentication (CIBA)

    +

    Client-Initiated Backchannel Authentication (CIBA)

    Client Initiated Backchannel Authentication (CIBA) enables a Data Recipient (Client) to initiate the authentication of an end-user at a Data Holder (OpenID Provider) by means of decoupled or out-band mechanisms [FAPI-CIBA].

    @@ -1741,11 +1637,11 @@

    4.2. Client-Initia

    Client rules for [FAPI-CIBA] are outlined under section 5.2.3 of the FAPI CIBA profile.

    -

    5. Client Authentication

    +

    Client Authentication

    Data Holder's MUST support the private_key_jwt Client Authentication method specified at section 9 of [OIDC].

    The PKI Mutual TLS OAuth Client Authentication Method SHALL not be supported. However as specified under section 11.2, all back-channel communication between Data Recipient and Data Holder systems MUST incorporate, unless stated otherwise, MTLS as part of the TLS handshake.

    -

    5.1. private_key_jwt

    +

    private_key_jwt

    Non-Normative Example

    @@ -1799,9 +1695,9 @@

    5.1. private_key_jwt

  • client_assertion_type: This MUST be set to urn:ietf:params:oauth:client-assertion-type:jwt-bearer.
  • client_assertion: The encoded assertion JWT.
    • -

    6. OIDC Client Types

    +

    OIDC Client Types

    Only Confidential Clients SHALL be supported under this profile. Therefore, Public clients SHALL NOT be supported.

    -

    7. Tokens

    7.1. ID Token

    +

    Tokens

    ID Token

    Non-Normative Example - acr

    @@ -1855,22 +1751,22 @@

    7. Tokens

    7.1. ID Token

    -

    7.1.1. Hashing value for state and authorisation code

    +

    Hashing value for state and authorisation code

    The c_hash value MUST be generated according to section 3.3.2.11 of [OIDC].

    The s_hash value MUST be generated according to section 5.1 of [FAPI-RW].

    -

    7.2. Access Token

    +

    Access Token

    Access Tokens MUST be used as specified in section 10.3 of [OAUTH2]. An Access Token MUST expire n minutes after it is issued by the Data Holder where n is determined by [CDR] rules.

    The process for refreshing an Access Token is described in section 12.1 of [OIDC].

    -

    7.3. Refresh Token

    +

    Refresh Token

    Refresh Tokens MUST be supported by Data Holders. The usage of Refresh Tokens is specified in section 12 of [OIDC]. A Refresh Token MUST expire n days after it is issued where n is determined by [CDR] rules.

    -

    8. Scopes and Claims

    +

    Scopes and Claims

    Industry-specific scopes (for example, bank_account) will not be referenced in this profile.

    -

    8.1. OIDC Scopes

    +

    OIDC Scopes

    The following scopes MUST be supported:

    -

    8.2. Claims

    +

    Claims

    The following normal [OIDC] claims MUST be supported. This list includes, but is not limited to, [OIDC] standard claims :

    -

    9. Identifiers and Subject Types

    +

    Identifiers and Subject Types

    The identifier for an authenticated end-user (subject) MUST be passed in the sub claim of an ID Token and UserInfo response as defined by [OIDC]. The Data Holder MUST generate the sub value as a Pairwise Pseudonymous Identifier (PPID) as described in section 8 of [OIDC]. Furthermore, the identifier SHOULD also be unique relative to the scenario in which the end-user has authenticated. For example, the identifier generated for the same person when they are using a business account SHOULD be different to the identifier that is generated when that same individual is authorising as an individual.

    @@ -1913,7 +1809,7 @@

    9. Identifiers and Subject Types

    Identifier (UUID) [RFC4122].

    -

    10. Levels of Assurance (LoAs)

    +

    Levels of Assurance (LoAs)

    Levels Of Assurance (LoAs), returned after a successful authentication, MAY be represented in 2 different forms:

    -

    10.1. Single Ordinal

    +

    Single Ordinal

    A Single LoA value is carried in the acr claim which is described in section 2 of [OIDC].