More news...

I don't think I shared this with you-all...

GEFFEN RECORDS OFFERS SIMPLE SIGN ON FOR MUSIC LOVERS

ooTao, a Leader in Open Identity Management, Partners with Record Label

June 12, 2007 (Berkeley/Los Angeles) – Geffen Records, has partnered with ooTao, a leader in Open Identity (Open ID) management, to make it easier for music lovers to log on and connect with all their favorite artists, such as Snoop Dogg, Mary J. Blige, the Cure, Nelly Furtado, Trevor Hall, and Ashlee Simpson. The new “Single Sign-On” launches June 18 and will be expanded to include other Geffen artists as well as new services for fans.

Lee Hammond, Director of New Media for Geffen Records, has been working with ooTao President Andy Dale for almost a year to make it easier and more secure for fans to log on with a single user identification, or i-name. Says Hammond, “We love the promise of OpenID to reduce registration barriers for newcomers to our properties as well as make it easier for current audiences to crossover to new artists’ content.”

Artists love the new feature, too, said ooTao’s Dale, because music lovers no longer have to sign off and sign in again every time they want to see what’s happening with an artist. Using the same i-name, says Dale, fans can sign into the Geffen site and read about and listen to the music for their favorite artists without leaving the site.

More is in the works, adds Dale. “After this initial phase goes live on June 18, we expect to continue working with Geffen to leverage these identity standards and bring music lovers truly innovative services that allow them to get closer to the music and the artists.

ooTao (ooTao.com) is an engineering development company specializing in distributed data sharing and identity management infrastructures. Its founding partners are leaders in developing standards for Open Identity management.

#####

Expediting XPP

I am hoping to quickly and painlessly work up a basic 1.0 spec for XPP (XRDS Provisioning Protocol). This should be simple and easy to implement. I am going to drive the process and try to get the spec done in the next month… then people can use it, or not.

If you want to be a part of this open process add your name to the people section on the front page of the xpp wiki at http://xpp.seedwiki.com. I will organize a conference call for the middle of next week for anyone that wants to play with me.

Validating i-name claims.

There will be many ways in which people will assert claims over the internet and depending on the nature of the claim and the identity of the claimant we will have to do different types of validation. I’m talking about claim validation in a dynamic trust environment, in a distributed identity network. There is no assumption of a prior relationship between the asserting party (AP) and the Relying Party (RP).

When I talk about validating a claim what I’m really talking about is; is there a way for the RP to be sure that the AP can be trusted for this specific claim. When I say ‘this specific claim’ I mean 2 things;

1) that the AP is trusted by the community to make this claim type (just because they are trusted for one claim doesn’t mean they should be trusted for all claims)

2) that the identifier about which the claim is being made has indicated that this is their designated AP for this claim. (I think this is only an issue in some claim types)

Specifically I am starting with i-name claims and I will explore this from an InfoCard perspective. This is a totally valid way to authenticate ‘ownership’ of an i-name although the mechanism is totally different from an http redirect authentication protocol like OpenID, BBAuth, Google’s SAML implementation, etc… In the http redirect case the i-name is the identifier and therefore validation/authentication of ownership is the point of the entire interaction. In the InfoCard case the i-name is just another piece of metadata associated with the PPID. Self asserted claims about i-name ownership should never be accepted.

So here’s what an RP should do when they get an i-name claim via InfoCards…

Perform SEP resolution to find the designated ‘InfoCardService’ published by the owner of the i-name. The only AP that should be acceptable for claims about that i-name should be that entity. This should be enough validation. (Obviously you are checking the crypto to make sure that the AP is who they say they are.)

In order to defeat this validation a would-be spoofer would have to have subverted the XRI resolution and inject their own SEP; if the RP is using the http proxy resolver this can be achieved by subverting the DNS layer. Once I start to assume that DNS is compromised any validation starts to fall apart… so either use a local resolver in trusted resolution or some other mechanism of trusting your resolution infrastructure if you deem it necessary… personally I’m not sure that the value of the i-name claim in this context requires a particularly high level of paranoia. In the InfoCard usecases it’s the PPID that is the identifying key, and any additional services derived from the i-name should be separately validated anyway.

Final word on XRDS… for now

So while posting a comment to Phil’s blog on this thread I finally hit upon the thing that I have been trying to say in a clear concise way… Sorry you have had to watch me formulate this idea in real time.

The simple statement is this:

SEPs in XRDS must be considered self asserted claims and as such should not be trusted on their face. Service Providers should publish the mechanisms by which SEP claims should be validated to be about a specific subject (authenticated identifier). (ooo… I feel another spec coming).

Even More on XRDS.

Phil Windley picked up the XRDS conversation with a great post. I just want to reiterate my concern about misunderstanding of XRDS usage. You may have all already groked this in which case I apologize for the redundancy but I want to make sure that this is really clear.

The problem is this:

Lets say that I have 2 services listed in my XRDS, an OpenID authentication service and a photo service. I go to a dating service and log in using my OpenID. The dating service now looks for a photo service in my XRDS and finds it and presents the photos found as photos of me. The danger here is that because I logged in using one service listed in my XRDS that there is the impression that the there is some validation that the photos really are of me, this simply isn’t true.

All you can derive from the fact that multiple services are listed in a specific XRDS is that one of the entities that have access to edit that XRDS want to associate that service with that identifier. Service endpoints in XRDS documents should be treated like any other self asserted claim.

At this point I want to give a big thanks to Steven Churchill, ooTao’s CTO. I recognized this vulnerability of XRDS and discussed it with Steve, he then went ahead and solved the problem at least as it pertains to i-name resolution and services in XRDS. His solution is now a part of the XRI resolution specification, lookup Canonical ID verification.

Some things that do work:

If you know that services use the Canonical ID as their ‘key’ then you can use canonical ID verification to ensure that the same i-number is the subject of both your authentication request and your service access request. Assuming the service has authenticated and validated the user correctly when the service was provisioned you can use this mechanism to create trusted service bindings. The trouble here is knowing which service providers to trust, both in intent and implementation.

A simpler case that does work is the case like EZIBroker’s Claim Services. In this case the semantics of the services itself asserts the relationship between the services and the identifier. This works equally well with URLs or i-names (I think). A user authenticates (demonstrates their access to the credentials for a given identifier) using a specific OpenID identifier. The relying party then looks up the ‘claims service’ (could be WS-*, SAML, AX, XDI, etc…) The assertions that are generated by the claims service specifically assert the claim and the related identifier. For Example: signed {=andy is over 21}. If you find this claim from a service in =andy’s XRDS then it makes a lot of sense… If you find it from =jim’s XRDS you know there may be a problem. (of course if =andy and =jim resolve to the same canonical ID then it’s all good). A service that presents the claim; signed{this person is over 21} is obviously not useful in the context of an XRDS unless there is an additional authentication step that lets the user assure the Relying Party that they are ‘this person’.

NOTE: The EZIB claims service will be providing one-time opaque identifiers that can be used with claims so the relying party only need know that !2003!1928.2746 is over 21 and !2003!1928.2746 is the person logged in. This will satisfy some of the privacy concerns but not all, we are not claiming that we are building a zero knowledge system.