Microsoft Labs STS
This was briefly available a few weeks ago...looks like it's live again:
http://sts.labs.live.com/
Haven't tried it yet myself, but it looks interesting.
Wednesday, June 07, 2006
Subscribe to:
Post Comments (Atom)
Tags
- cardspace (34)
- didw (1)
- firefox (8)
- iddy (1)
- infocard (34)
- openid (1)
- reardencommerce (2)
- selector (9)
- snowboarding baldface (1)
CardSpace Blogroll
- http://www.hccp.org/blog/
- http://blogs.sun.com/superpat
- http://www.directorymanager.org/blogs/
- http://blogs.sun.com/wizidm
- http://netmesh.info/jernst/
- http://itickr.com/
- http://www.identityblog.com/
- http://eternaloptimist.wordpress.com/
- http://discuss.andredurand.com
- http://blogs.msdn.com/garretts
- http://www.cardcarrying.info/
- http://blogs.msdn.com/andyhar
6 comments:
Where are the specification for "identity metasystem 'clients'", meaning providers, browsers and relying parties?
Surely, they must exist, but under which names?
I'd be greatful for any pointers on that.
Also, I was thinking about PPI(D) claim, present in an InfoCard (identity card -- how does one call it 'independently'? :)) -- the specification I found on that are only in Microsoft papers and even there, it is just mentioned that it is base64 encoded byte array...
Thank you,
Miha.
Here's a link to all the infocard...err...cardspace docs:
http://msdn.microsoft.com/winfx/reference/infocard/default.aspx
As far as PPI, to quote Kim Cameron:
This is basically an unchanging identifier for the given user at the relying party. It could be, for example, a hash of the relying party’s DN plus the account number of the user (or in your case the email address, if that is considered unchanging). In the simple self-asserted identity provider we do it as a function of the site identifier (e.g. from the cert) and the infocard identifier. Thus if I go to the same site with the same infocard, I’ll get the same privatepersonalidentifier even if I change my email address.
The format is basically opaque to the relyingparty.
I found those documents, but they are Microsoft documents, explaining API and CardSpace (client more or less). It is not ... specification for implementation of an identity metasystem. For instance, how the client and server should negotiate (WS-Policy?) what algorithms must be supported (as to enable at least some sort of interoperability), what encodings, what token formats (SAML, eToken,...?) should be support and so on.
I understand CardSpace is currently mostly Microsoft business, but given the plans to adopt it throughout industry, wouldn't it make sense to have some sort of specification [draft] to work with and evolve it?
As for the PPI(D), I believe there should be some limitations to what it is, in terms of size at least. The way it is specified right now, someone can put 1GB base64 encoded byte array.
On another note, how can CardSpace be used on sites without SSL (server side certificate), when this certificate (well keys in it actually) are used to cryptographically sign and encrypt the token and token "envelope".
Regards,
Miha.
All excellent points, and I'm in complete agreement.
Some of the protocols involved are moving through the standardization process, and some are still proprietary and closed. Hopefully those all open up.
As far as SSL, I don't think CardSpace will work without it in current form.
Basically, you're starting to ask lots of very relevant questions, that I'm only in a position to speculate on...wish I could help more, but I don't work for MSFT, and have no control over their implementation, nor what they release to standards bodies.
FYI John Shewchuk on panel at the Burton Group Catalyst conference mentioned that all the InfoCard protocol specifications would be available (in the context of open source developers i.e. Higgins project) and to contact him if this was not the case.
I'll have to drop John a line :-)
Post a Comment