Superpat and the third way

Pat Patterson leaps through the firmament to punctuate my recent discussion of minimal disclosure with this gotcha: 

But, but, but… how does the relying party know not to ask for givenname, surname and emailaddress the second (and subsequent) time round? It doesn't know that it's already collected those claims for that user, since it doesn't know who the user is yet…

In the case described by Pat, the site really does use a “registration” model like the one from BestBuy shown here. 

When registering you hand over your identity information, and subsequently you only “authenticate”. 

This is really the current model for how identity is handled by most web sites.  In other words the “Registration process” is completely separated from the “Returning user” process.

So the obvious answer to Pat's question is that when you press “create an account” above, you invoke an object tag that asks for the four attributes discussed earlier.  And if you press “Sign in”, you invoke an object tag that only asks for PPID and then associates with your stored information.  

In other words, there is no new problem and no new framework is required.

This doesn't prevent Pat from serving up a little irony:

If only there were some specification (perhaps part of some sort of framework) that, given a token from an authentication, allowed you to get the data you needed, subject, of course, to the user's permission. 

I guess it bothered Pat that I didn't include use of backend protocols as one of the options for reducing disclosure. 

I want to set this right.  I've said since the beginning that as I saw it, the PPID (or other authenticated identifier) delivered by an InfoCard could also be used to animate a back-end protocol such as he's refering to.  That's one of the reasons I thought everyone should be able to rally behind these proposals.

The third option

So let me add a third alternative to the two I gave yesterday (storing locally or asking the user to resubmit through infocard).  The relying party could authenticate the user using InfoCard and then contact the identity provider with the user's PPID and ask it for the information the user has already agreed should be released to it.  This could be done using the protocols referred to by Pat. 

My uberpoint is simple.  InfoCards are intended to be as neutral as possible in their technical assumptions (e.g. to be an identity platform) and can be used in many ways that make sense in different environments and use cases.

I don't personally agree that the back-end protocol route for obtaining attributes is either simpler or more secure than delivering the claims directly on an as-needed basis in the authentication token, but it is certainly possible and I'm sure it has its use cases.  I wonder if Pat's implementation of Information Cards, should there be one, will take this approach?  Interesting.