The process of registering a card is straightforward (at least currently, it seems that you must have a username/password account to which you 'add' cards). I did notice an oddity though.
After registering a card, I edited that same card (adding my postal code). I was hoping that the new info would be communicated to SignOn.com (the next time I presented the card), and used to populate the profile (where it could then be sent to requesting OpenID RPs). This didn't happen.
A peak under the HTML covers shows that this is because SignOn.com isn't asking for the postal code, it's not on the list of 'required' claims
<object id="_xmlToken" type="application/x-informationCard">
<param name="requiredClaims"
value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"/>
<param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:>
<param name="issuer" value="http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self"/>
</object>
So SignOn.com isn't willing to ask Cardspace for the postal code (presumably because it fears rejection), but it is willing to ask me (it's on the profile page).
Even though I had entered the postal code into the card, because SignOn.com didn't ask Carddspace for it, I am presented with an empty form field asking to be filled in. Does SignOn.com want it or not?
SignOn.com is of course only asking me for the postal code because they anticipate that they themselves might be asked for it through OpenID. As a result, if I want to ensure that these eventual RPs get my postal code, I will have to enter it a second time beyond the value in the card.
The disconnect here is between the identity demands of the 'application' (the bit of SignOn.com that wants to provide postal code data to RPs) and the multiple 'query mechanisms' by which that data is obtained (both the HTML profile page and the Cardspace 'required claims' parameter). As it stands, the two query mechanisms are asking for different amounts of identity so its impossible to know what the application actually 'wants'. Ideally, the application would be able to indicate what identity it needed, and the query mechanisms would be driven accordingly (e.g. ensuring both sets of HTML were consistent) This is the CARML proposition.
Client Attribute Requirement Markup Language (CARML) is an XML-based language used by application developers to specify what identity information an application needs and how the application will use it.
The issue of course isn't unique to SignOn.com, or to Cardspace, this specific scenario just illustrates the challenges faced when identity flows through multiple providers (especially when intermediate ones collect identity on their own).
Ensuring that the user's privacy policies also flow with the data is a whole different ball game.
Tags:
2 comments:
The idea of CARML certainly isn't new; lookie here:
http://citeseer.ist.psu.edu/22543.html
Paul - this raises an interesting question and one that we haven't really thought about - if I want to use a certain service, I might want to find out WHAT personal information is required before using the service. That would be an interesting use of the CARML-model; another reference that is related is Anne Anderson's WS-XACML privacy policies.
Eric - i took a look at your reference and couldn't find the CARML-related pub. Did you have a different reference in mind?
Post a Comment