Welcome to the Consumer Data Right Support Portal

Check out our guides, browse through our FAQs, and post your own questions for Support.

New to the Consumer Data Right? Learn more

Consent sequence diagrams Follow

Avatar
Neale Morison
  • Created:
  • Last edited:
  • Updated

Introduction

The following sequence diagrams provide detail of the interchanges between consumer, ADR and DH In the course of consent, authentication, authorisation and data sharing.

For a video walkthrough of these sequence diagrams, see Consent Flow, Part 2.

Consent sequence diagram 1 - preparatory sequence

cdr-prep-sequence.png

 

Consent sequence diagram 2 - consent sequence

cdr-consent-sequence.png

 

UML files and png files

 

Comments

3 comments

Sort by Date Votes
  • Avatar
    Shang Chen

    Hi there,

    I found this diagram very useful but there is one thing that might not be 100% correct.

    In the "preparatory sequence" section, as illustrated in the diagram,  the Data Holder should be able to cache ADR's JWKs beforehand. But as stated in CDS(Security Endpoints – Consumer Data Standards (consumerdatastandardsaustralia.github.io)), Data Holder should only be able to get ADR's JWKs in SSA during the dynamic client registration. And I checked that ADR's JWKs URI couldn't be retrieved from participant endpoints provided by register either. 

    0
    Comment actions Permalink
  • Avatar
    Stuart Low

    A bunch of inaccuracies here:

    1. A PAR request must be validated at submission as if it was submitted at the authorisation endpoint. This diagram has the client parameters and content validation at Step 2, this is incorrect and is in fact a common non-compliant behaviour observed in the ecosystem
    2. Returning a refresh token is optional if the requested consent length is 0
    3. Refresh token cycling is no longer permitted
    4. Hybrid flow c_hash/s_hash validation is mandatory and this requires ID Token decryption. This matters in disclosure because it significantly increases the complexity of implementation for newcomers.
    5. "Validate authorization-code and ensure it relates to an initiated consent" is completely incorrect. The ADR cannot validate a code because it is one time use and opaque to them. In fact they correlate the state value or a previously set session (via cookie or similar) from the Consumer browser to check initiated consent.
    6. PKCE is now required for all PAR submissions so a largish part of this diagram is now wrong
    7. Code verifier validation is mandatory for recipients

     

    0
    Comment actions Permalink
  • Avatar
    Jarryd

    Shang Chen

    There are two different concepts at play here:

    1. The URI that the ADR makes available or obtain the keys (ie. the JWKS end point)
    2. The actual keys that can be obtained from the JWKS end point (ie. the keys themselves)

     When the standards talk about the JWKS being in the SSA it is referring to the URI (ie. the location to call to get the keys).  The diagram, however, is talking about caching the keys obtained from that end point (ie. the actual key set) so that the keys can be used multiple times without having to continually hammer the ADR's JWKS end point.

    0
    Comment actions Permalink

Please sign in to leave a comment.