AudienceRestriction

The xmldap relyingparty (svn version 339 or newer) now displays the subject's confirmationmethod:

urn:oasis:names:tc:SAML:1.0:cm:bearer or urn:oasis:names:tc:SAML:1.0:cm:holder-of-key

and the audience restriction.

...
<saml:Conditions 
 NotBefore="2007-08-21T07:18:50.605Z" 
 NotOnOrAfter="2007-08-21T08:18:50.605Z">
 <saml:AudienceRestrictionCondition>
  <saml:Audience>
   https://w4de3esy0069028.gdc-bln01.t-systems.com:8443/relyingparty/
  </saml:Audience>
 </saml:AudienceRestrictionCondition>
</saml:Conditions>
<saml:AttributeStatement>
 <saml:Subject>
  <saml:SubjectConfirmation>
   <saml:ConfirmationMethod>
    urn:oasis:names:tc:SAML:1.0:cm:bearer
   </saml:ConfirmationMethod>
  </saml:SubjectConfirmation>
 </saml:Subject>
 ...

Here are two screenshots of the relying party:
First the assertion generated by the Firefox id selector:

Second the assertion generated by Windows CardSpace:

The scrupulous reader of this blog will notice that this Firefox id selector generated a bearer token, while I claimed here, that it generates holder-of-key tokens. I am still investigating why the Microsoft Demosite FriendsWithCards does not accept my tokens :-| It still says that the signature is wrong... That's why I want the token to be as similar to the CardSpace one as possible.
Anyways, with the help of Microsoft we will find the reason for this. Thanks to Marc, Mike and Kim.
Back to the topic of this post: It is good that the xmldap relyingparty now shows the audience restriction.

LiveId not supporting Firefox Id Selector (or vice versa?)

Christian Arnold reports that Microsoft Live is now supporting (beta) Information Cards.
I tried this with the Firefox Id Selector but...


Well, I don't know what's wrong here. Maybe it is the same issue as with FriendsWithCards...? Mike Jones told me he will have somebody look into the FWC issue. I fixed the computation of the thumbprintsha1 inside the Firefox Id Selector, which now computes the digest of the entire certificate bytes (instead of the digest of the public key bytes). FWC could not find the certificate, while other relying parties just use the certificate of the SSL connection, instead of searching for the certificate.
But still FWC does not like the SAML assertion generated by the Firefox Id Selector :-(

Besides: LiveId is no major Internet business according to Microsoft CardSpace:

BTW: How do I remove my information card from the LivID profile? Could not find this option. Maybe a typical user management one way street?

Self-Issued Cards, SIC!

I feel that the focus of Windows CardSpace changed from providing claims to be a mere login mechanism with claims dangling behind it.

Are relying parties really using the provided claims? Will relying parties use the provided claims in the future?

I think that enabling the user to control the claims provides a way to get rid of most of the user management at the RP.
No more "Edit your profile" webpages which are different from site to site.
Just edit your information card and use it. All sites will get the new updated information about you.
But what if the RP needs more/different claims than the standard self-issued ones. Today we would need to introduce an identity provider that issues managed cards with that set of claims.
Why are we not extending the self-issued token server to serve any set of claims?

The user would still be in control of his claims.

Habits

Yes, I read xkcd and hope the author does not mind my abuse of this comic strip.
Read this to understand the tooltip in the original comic.

Presentation of Claims

As I wrote in a previous post I added a demo geopriv STS to the openinfocard code repository which manages civic addresses. As claim's identifiers I used URLs inspired by rfc4119 e.g.
urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc:A6 (street name without number)
You might have seen here and in the image above that the presentation of these claims in the id selectors GUI is, well, not satisfying.
The displaytag and the claim's description from the information card are not very helpful in the case of civic addresses. Maybe the rendering information should be attached to the DisplayToken instead of to each DisplayClaim.
The format of an rfc4119 civic address was designed to work around the globe which makes it a little bit difficult to handle.

Which choices do I have as an id selctor and/or STS?

• I could use a (deep versus flat) claim: ietf:civicaddress which has an XML civicaddress as it's value.
  Current id selectors would display this in one line... Not pretty
  Future id selectors would know that the value of the claim ietf:civicaddress is not a plain text but XML which should be rendered as a user expects it.


• I could enhance the id selector to render claims of this kind appropriately.
  I would have to do this for every new set of claims. -> not elegant


• The STS could include an XSLT (XML geopriv civicaddress to HTML) script to render the claims in the id selector.
  Maybe the RP does know how to render the claims better?
  Maybe the user knows how to render the claims better?


• The RP could render the claims while I chose which card to present.
  This is not desirable, because the RP would learn about all my cards.


• The id selector could render the claims using CSS/XSLT provided by the RP
  Do I trust the RP this much?


• The id selector could render the claims using it's own (provided by the user?) CSS/XSLT script.
  Only a few users will be able to understand this.

More questions than answers. Sorry.

The flat versus deep claim's value needs more discussion too. Maybe it is another side of the same coin? Not.
Mark Wahl has put this far better than me in this short post. His posts are here and here.