Introduction
The Data Standards Body has provided a proposal for the definition of Purpose Based Consents within Decision Proposal 183 (DP183). In addition to a number of specific questions, the primary approach proposed appears to be the definition of additional OAuth2 scopes (also referred to as Data Clusters) with the apparent intent to define common use cases in a consistent way.
Such a use case defined approach would allow Holders to uniformly apply the constraints across their systems and Recipients to streamline their product delivery potentially coupled with a streamlined accreditation process and/or tier.
References
The following documents were used and are referenced during preparation of this analysis:
|
Document Name |
Date (Version) |
URL |
| OAuth 2.0 Rich Authorization Requests (RAR) | 16 Nov 2021 (Draft 5) | https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-05 |
| Grant Management for OAuth 2.0 | 15 July 2021 (Draft 2) | https://openid.net/specs/fapi-grant-management-02.html |
| Decision Proposal 183 | 13 June 2021 (Update 2) | https://github.com/ConsumerDataStandardsAustralia/standards/issues/183 |
| JSON Web Signature (JWS) | May 2015 (RFC7515) | https://datatracker.ietf.org/doc/html/rfc7515 |
| OpenID Connect for Identity Assurance 1.0 (Implementers Draft 2) | 5 May 2020 (Draft 10) | https://openid.net/specs/openid-connect-4-identity-assurance-1_0-ID2.html |
Benefits
There are a number of potential policy benefits to the delivery of Purpose Based Consents notably:
- Common (“purpose”) use cases would facilitate simplified consent flows
- Technical application of a defined purpose could facilitate strong business rules such as mandating all accounts (for mortgage assessment), limiting transaction visibility to 6 months (for credit applications)
- Purpose based permissions at a Register level would likely limit “blast radius” potential in the event of compromise
Risks
While there are a number of obvious benefits the introduction of Purpose Based Consents also appears to carry a number of risks notably:
- Technical complexity if not considered in the broader context of international standards
- Brittleness in implementation if attempted to be “shoe-horned” into the existing arrangement establishment method
- Innovation could be impacted if Purposes are prioritised above, rather than in tandem with, multi-dimensional arrangement definition.
Current State
The Data Standards currently specify an arrangement as a combination of:
- API Endpoint-based, coarse-grained OAuth2 scopes and;
- A custom claim specifying a length of time to share from the initiation
There is currently limited opportunity, while retaining a single consent process, to introduce additional orthogonal characteristics including:
- Intervals of access within an arrangement including;
- Per API, for example Once Off for Transaction History but continuous for Account Balances
- Per Data Cluster, for example Once Off for Detailed Customer Information but continuous for Basic Customer Information
- Depth of event history, for example transactions for the last 12 months instead of the last 3 years
- Mandated business rules, for example:
- requiring all accounts to be shared
- the user to be over a certain age
Within Decision Proposal 183 the word scope is used in a number of contexts and situations that results in its meaning being overloaded, such as data scopes, coarse grained scopes, purpose specific scope, specific data scopes, the scope, specific scope. Biza.io prefers to adopt the definition of a scope being its definition according to the OAuth2 specification such that the scope parameter, put simply, controls access to one or more API endpoints with very limited or completely absent business rules applied.
As we read DP183, what appears to be implied, but never specifically stated, is that the OAuth2 scope would in essence be ‘overloaded’ with a “purpose scope” to trigger business rule behaviour such as limiting the length of time data was retrieved for, the required age of a consumer etc. Such an approach would result in a system property (permission to access an endpoint) being used to deliver business rules (data access constraints). This would be an architecture anti-pattern and, as far as we are aware, completely divergent from any international standard or expert guidance.
Consent Taxonomy Potential
As outlined in its response to DP182, Biza.io believes that the key to achieving suitably defined consent is the definition of a consent taxonomy that can be uniformly defined, expanded upon and adopted across industries using existing (RAR) and emerging (GM-API) technical standards coupled with an appropriate legal framework.
In order to demonstrate how this could be applied Biza.io provides examples of potential authorization_details (RAR) with a type of cdr_sharing_arrangement_v2. Internally Biza.io already manages CDR Arrangements using a RAR type of cdr_sharing_arrangement_v1.
With regard specifically to Purpose Based consents, such blocks could be signed directly by the appropriate regulator and included as, potentially mandated, “cookie-cut” request parameters to authorised Data Recipients. By approaching the problem space this way it is possible to deliver Purpose Based Consent while:
- remaining aligned locally with respect to using the same process for flexible arrangement initiation
- remaining aligned to the direction of travel internationally
- retaining machine parsability throughout a Holder technology stack
- continuing to be able to trigger specified CX workflows
- removing the requirement to apply various negative business rules (ie. “not able to request additional scopes”, “don’t restrict concurrent consents”)
Further, in switching to utilising rich authorisations, Biza.io would suggest that what is currently referred to as “scopes” is instead referred to as “permissions” with the OAuth2 scope parameter instead being used as a transition method between the existing coarse-grained consent model to the fine-grained consent model.
Note: The following examples are purely hypothetical and are intended simply to demonstrate desired behaviours are transparently possible with existing standards.
Hypothesis 1: Product Comparison Consent
The following Data Recipient business requirements appear to be presented in the example:
- A List Account Detail which contains the bundleName, depositRate, lendingRate, depositRates, lendingRates and features fields
- A Get Customer Detail which incorporates a state of residence and age cohort (currently missing attribute)
- A once-off consent requiring no ongoing access
Example Request
{
"iss": "s6BhdRkqt3",
"exp": 1516239322,
"aud": "https://www.recipient.com.au",
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://www.recipient.com.au/coolstuff",
"scope": "cdr:rich_authorisation",
"nonce": "n-0S6_WzA2Mj",
"state": "af0ifjsldkj",
"authorization_details": {
"type": "cdr_sharing_arrangement_v2",
"sharing_duration": 0,
"permissions": ["common:customer.detail:read", "bank:accounts.detail:read"],
"data": {
"account": {
"include": [
"bundleName", "depositRate", "lendingRate", "depositRates", "lendingRates", "features"
]
},
"customer": {
"person": {
"include": ["age_cohort"],
"physicalAddresses": {
"include": ["purpose"],
"paf": {
"include": ["state"]
},
"simple": {
"include": ["state"]
}
}
}
}
}
}
}
Hypothesis 2: Credit Application Consent
Within this hypothesis the Data Recipient requires enough detail for the purposes of applying for a mortgage. This example incorporates a number of data sets which are not currently defined, notably net assets & liabilities as well as summarisation of incomings & outgoings.
For the purposes of this example Biza.io makes an assumption that such data would be available at prescribed endpoints with permissions of bank:business.balance_sheet.read and bank:personal.transaction_summary:read .
Example Request
As this request uses purely permissions the request would be relatively simple.
{
"iss": "s6BhdRkqt3",
"exp": 1516239322,
"aud": "https://www.recipient.com.au",
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://www.recipient.com.au/coolstuff",
"scope": "cdr:rich_authorisation",
"nonce": "n-0S6_WzA2Mj",
"state": "af0ifjsldkj",
"authorization_details": {
"type": "cdr_sharing_arrangement_v2",
"sharing_duration": 0,
"permissions": ["common:customer.detail:read", "bank:business.balance_sheet.read", "bank:personal.transaction_summary:read"]
}
}
Footnote: A reference is made to the “LIXI standards” which is an established but proprietary member only specification. While Biza.io is supportive of using existing standards this support is conditional on sufficiently permissive licensing of underlying standards.
Hypothesis 3: Tax Return
Within this hypothesis the Data Recipient requires time based data for a specific financial year including the common:customer.basic:read, bank:transactions:read and bank:accounts.basic:read permissions. There does not appear to be a specific need within this scenario to define any additional endpoints.
Example Request
Within this request the permissions remain relatively simple however in addition to a sharing_duration being defined (representing the Data Recipients access to the data in question – 24hrs) we also introduce an epoch based start and finish time (1 July 2020 to 30 June 2021) transaction data constraint.
{
"iss": "s6BhdRkqt3",
"exp": 1516239322,
"aud": "https://www.recipient.com.au",
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://www.recipient.com.au/coolstuff",
"scope": "cdr:rich_authorisation",
"nonce": "n-0S6_WzA2Mj",
"state": "af0ifjsldkj",
"authorization_details": {
"type": "cdr_sharing_arrangement_v2",
"sharing_duration": 86400,
"permissions": ["common:customer.basic:read","bank:transactions:read", "bank:accounts.basic:read"],
"data": {
"transaction": {
"constraint": {
"time": {
"from": 1593525600,
"to": 1625061599
}
}
}
}
}
}
Hypothesis 4: Limited Online Contact Details
Within this hypothesis the Data Recipient requires a subset of the existing common:customer.detail:read permission.
Example Request
This request uses the previously exampled include pattern to subset customer details to the firstName, lastName, emailAddresses and phoneNumbers attributes.
{
"iss": "s6BhdRkqt3",
"exp": 1516239322,
"aud": "https://www.recipient.com.au",
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://www.recipient.com.au/coolstuff",
"scope": "cdr:rich_authorisation",
"nonce": "n-0S6_WzA2Mj",
"state": "af0ifjsldkj",
"authorization_details": {
"type": "cdr_sharing_arrangement_v2",
"sharing_duration": 0,
"permissions": ["common:customer.detail:read"],
"data": {
"customer": {
"person": {
"include": ["firstName", "lastName", "emailAddresses", "phoneNumbers"]
}
}
}
}
}
Hypothesis 5: Identity Confirmation
Within this hypothesis the Data Recipient requires a subset of the existing common:customer.detail:read permission.
Example Request
This request uses the previously exampled include pattern to subset customer details to the firstName, lastName and a newly introduced adult boolean.
{
"iss": "s6BhdRkqt3",
"exp": 1516239322,
"aud": "https://www.recipient.com.au",
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://www.recipient.com.au/coolstuff",
"scope": "cdr:rich_authorisation",
"nonce": "n-0S6_WzA2Mj",
"state": "af0ifjsldkj",
"authorization_details": {
"type": "cdr_sharing_arrangement_v2",
"sharing_duration": 0,
"permissions": ["common:customer.detail:read"],
"data": {
"customer": {
"person": {
"include": ["firstName", "lastName", "adult"]
}
}
}
}
}
Special Note
Biza.io wishes to highlight that this hypothetical scenario appears to suggest that the Data Standards may potentially seek to enter the space of Identity Assurance. While such an aspiration is commendable we are of the opinion that such an initiative should be subject to separate consultation. As such, while we provide a potential solution as an example, we would not generally be supportive of such an approach.
Biza.io refers the Data Standards Body to the OpenID Foundation’s eKYC and Identity Assurance (eKYC & IDA) WG and the OpenID Connect for Identity Assurance 1.0 ID2 specification which would appear to cover all of the hypothetical requirements already with a growing number of implementations available worldwide.
Question Responses
Would Purpose Based Consents be a valuable tool for the CDR regime for specific scenarios?
Biza.io sees the value in the concept of Purpose Based Consents but believes it is likely to be a convenient regulatory optimisation for a significant technical impact. The technical impact after the adoption of a fine-grained consent model such as RAR is likely to be significantly reduced.
Biza.io is opposed to the development of Purpose Based Consents in isolation of the broader consent management questions as this would likely result in technical overbuild and divergence from the international direction. Biza.io is wary, and indeed weary, of non-technical and often politically driven decision making overriding well-considered technical reasoning.
What purposes would be worth considering for application of the concept of Purpose Based Consents?
Biza.io is broadly supportive of all of the hypothetical examples put forward within the Decision Proposal.
Would voluntary, or optional, scopes of this type be of value where the standards defined a series of Purpose Based Consents but data holders would not be required to implement them all?
Biza.io does not believe the application of scopes is appropriate for the adoption of Purpose Based Consents. Scopes, in the authorisation sense, by their very nature are coarse-grained, and attaching business rules to them will inexorably result in brittle technology development with limited international export capability.
Should purpose-based consents be explicitly governed so they can only be used for defined use cases with set terms?
Our opinion is that with a Rich Authorisation Request at play the focus of purpose-based consents could instead be on regulatory streamlining. That is to say that the government could identify use cases (as it has already done) and define standard request types which Data Recipients could either choose to follow, decide to develop a request completely separately or be explicitly accredited for.
Are there any specific characteristic clusters that should be defined or excluded?
The term cluster is used in a number of ambiguous ways when interacting with the DSB so we are uncertain how to respond to this question beyond stating a consent taxonomy would facilitate a way to filter, limit or range-specify any field within the dataset.
Should data recipients register for, or be accredited for, specific purposes that allows consumers to look up these registrations in a central purpose register or marketplace?
Biza.io can see value to Data Recipients being accredited for specific purposes as it would allow for more effective risk management and therefore potentially lower accreditation barriers.
Would there be value in exploring the concept of a simplified form of this concept where a high-level scope has its own CX language but is mapped to a series of existing scopes and no new APIs are created?
This question pre-supposes that a scope is the correct method of achieving this goal and wouldn’t, by its brittle nature, eventually encounter challenges as use cases expanded or orthogonal values such as request frequency or dataset ranging (ie. between x and y time) were requested or required to be introduced. Attempting to wedge these problems into a generic scope is only likely to exacerbate existing challenges with the Standards approach to consent.
In summary, Biza.io does not see any value in attempting to layer scopes and references the complexity of implementation that already exists with regard to the layering of basic, detailed and profile scopes with respect to CX language.
In discussing this paper within the DSB the possibility has been raised that rich authorisations (or fine grained consent) could amplify the benefits of purpose based consents. More granular authorisation, in the context of a specific purpose, could provide valuable control to the allowing for more granular consent to be provided by the consumer. Should the introduction of rich authorisation be considered alongside the concept of purpose based consent and, if so, what types of more granular consent should be considered?
Biza.io strongly believes that the adoption of RAR is a foundational component of a detailed consent taxonomy. We note the government within its hypothetical examples has already defined what types of more granular consent could be considered.
This combined with a migration approach for the existing consent model appears to be the most relevant tasks at hand rather than new, additional, hypothetical but also potentially commercially sensitive granular consent types.
Recommendations
Biza.io makes a number of statements with regards to the Decision Proposal for Purpose Based Consents:
- We support the construct of Purpose Based Consents
- We do not support the use of scopes with complex business rules as proposed
- We strongly recommend the DSB seek to adopt RAR as an underlying standard which will enable the delivery of Purpose Based Consents
About Biza.io
Biza.io are the market leaders in Data Holder solutions to the Consumer Data Right and are the only pure-play CDR vendor in Australia. Founded by the former Engineering Lead of the Data Standards Body (DSB), Biza.io has been involved in the Data Standards setting process since the very beginning and its personnel remain the largest non-government contributors to the consultations. In addition to its participation within the CDR, Biza.io is also a contributing member of the Financial-grade API (FAPI) Working Group, contributors to the FAPI 1.0 information security profile and co-authors of the Grant Management for OAuth 2.0 specification.
About Our Customers
As of July 2021, Biza.io is directly responsible for delivering, or heavily involved in, the verification of one in three of all active Data Holders. Beyond just a contractual engagement Biza.io considers all of its customers partners in the journey toward open data. Our customers choose us to not only achieve compliance but to compete then command the consumer data ecosystem.
