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

Reply via email to