NZ gov use case (SP - IDP (where logon service and Identity Verification Service are hypothetically one and the same)

[colin.wallis@ssc.govt.nz]

Greetings all

Can I grab your attention for a few minutes to take a look at a SAML use case we are westling with over here in NZ.  (Rob P is aware of this one at an earlier stage).

Issue is that the use case does not fit an existing profile, because of this phase in the middle where an HTML page is displayed and the user selects various elements and authorises their release. To my mind what we have is part-SAML part-bespoke, and that is OK, *provided* a SAML conformant/Liberty Interoperable product can do the job.  The long way around is to submit a new profile and wait for the standards and product development process to kick in. 

It may fit better into a LAP spec perhaps..  

OK so here goes. I'll put the graphic that goes with this in the Library now 

1) Principal attempts to access resource at SP(SA)

2) SP redirects principal's browser to logon at IdP 

3) SP challenge to principal

4) Principal response with High Strength Logon

5) The SP directs the Principal to the GOAS website to logon at high-strength.

then....

6) "It is assumed that as part of this action the SP will request some identity data elements from the IdP. IdP displays in the body of an HTML page(?) that it wants identity attributes before providing service 

The IdP displays the following:
a) 	The data elements that are required to be released to the SP, as provided in the Principal's original application form. 
i.	Name 
ii.	Gender
iii.	Date of Birth
iv.	Place of Birth
b) 	A statement of consent to release the required assertion to the secondary actor, and options to select this. 

7) The Principal gives consent to the IdP to release the assertion to the Service Agency.

8) The IDP displays:
a)	A question asking the Principal if they would like to use the same Logon each time they transact with this service agency;
b)	An option which can be selected to confirm.

9) The Principal confirms they wish to use the same Logon for future high-identity risk transactions with the SP. 

10) The IdP:
a)	Returns the required data elements to the SP;
b)	Displays an appropriate message confirming success to the Principal; 

11)	Redirects the Principal to the SP"

OK, so steps 6, 7, 8 seem to be out of scope for SAML profiles as they stand.
 
Steps 1 - 5, 11 look like normal Authn Request/Response.

Now all the while, the SP is hangin' in there after the redirect in Step 2, waiting for a response with a full blown assertion chocked full of identity attributes

What would you do?

Cheers

Colin