Introduction
The notes below are gathered from Subject Matter Expert guidance and responses to participant questions.
ID Permanence and PPID
The PPID (Pairwise Pseudonymous Identifier) is a concept equivalent to the sub or subject claim in the OIDC specification. Where the authenticated user is a secondary user, the PPID represents that secondary user, not the account owner. Where the authenticated user is a nominated representative, the PPID represents that nominated representative, not the entity they are representing. If two nominated representatives set up a consent with the same software product, then different PPIDs are issued for each. See ID Permanence and PPID for more detail.
URL safe characters for constructed URLs
All resource API calls must use valid URLs and must be url encoded.
PAR and ID Permanence
If the same account is shared under two different arrangements for the same subject, then the same ID must be provided. Keying the ID cipher
on the subject or a combination of subject and Accredited Data Recipient (ADR) client ID
would be more appropriate. This obviates the need for a change to pushed authorisation request (PAR).
Software Product resource IDs
It is acceptable to introduce user-specific resource IDs
per software product to address ID permanence
, instead of introducing user-specific resource IDs per ADR.
ID Permanence and Arrangement ID
ID permanence rules apply to the creation of IDs for pre-existing entities across multiple arrangements. As Arrangement IDs
explicitly identify a specific arrangement, which does not pre-exist, the ID permanence rules do apply. The mechanism for creating an Arrangement ID
is left to the Data Holder.
ID Permanence endpoint data availability
ADRs and third-party apps do not have visibility of the actual identifier value and have information only about the reference identifiers. ADRs store the reference identifiers and this information is used in the API calls to get CDR data from the Data Holder (DH). These reference identifiers have no meaning to consumers and should not be displayed.
The caveat is that occasionally the ADRs have the real identifiers but only if the appropriate scopes dictate this. For instance, accountId
is not the real identifier for an account but the account detail payload does include real account number and BSB as payload fields.
ID Permanence - Realisation by the Data Holders
There are a number of options to solve ID Permanence. Not all include the storage of the computed values in a data store. ID Permanence, itself, is not unique to the CDR and has been solved in other markets and problems. Employers can use shift ciphers, hashing algorithms or symmetric key encryption or a combination of these and computed storage. The solution is dependent on the DH's needs and constraints including infrastructure capacity, security requirements, and so forth.
ID Permanence fields clarifications
The Data Standards Body (DSB) confirms that the IDs listed accountId
, transactionId
, scheduledPayementId
and payeeId
are all subject to the ID Permanence rules.
Fields listed in the Scheduled Payments Schema:
bankingscheduledpaymentfrom
- accountId
bankingscheduledpaymentto
- accountId
require ID Permanence to apply. They should be the same accountId
as associated with the consumer's consent.
Comments
0 comments
Please sign in to leave a comment.