John Ehn wrote: > Martin, > > Thanks for the response! I'm looking at those specs now, and I really > like the flow of the HTTP Authentication spec, because it looks like > it's solving the problem of passing the OpenID Identifier to the RP in > an automated way, which is really cool. Looks like it needs to be > "fleshed out" in some parts, though.
Both of these "specs" need work. What you see up there on the wiki is really just a brain dump wanting to be turned into a spec. I've not really had much time to work on them, though. > As for the Signature Request protocol, I'm not quite sure what it does > yet, but I'll let you know my opinion once I've digested it. > The HTTP Authentication spec has a part in it where it says "the client must get a signature from somewhere". When I originally specced it my only answer here was that non-human agents can act as their own OP and therefore they could just compute the signature themselves, but realising that this protocol had applications for humans authenticating to services inside specialised rich clients (Last.fm's "Audioscrobbler" API, for example, or JOSM for OpenStreetMap) I added Signature Request Protocol as a standard mechanism for rich client RPs to obtain a signature from the user's OP. As I think it notes somewhere in the copy, I'm imagining in the ideal case a desktop service or at least a shared library that does the SRP bit on behalf of all of the user's applications, so that each application does not need to be given the user's OP credentials. It was my hope that it could theoretically be integrated with systems like Apple's Keychain. However, SRP is still very rough-and-ready and still has lots of outstanding issues. I think Inline Authentication might have the answer to some of these issues. Cheers, Martin _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs