> Great start on the Wiki. Note that there are some efforts in IETF for > enhancing what can be done at the TLS layer for authentication which > would enable the same mechanism to be used not only for HTTP, but for > SMTP, POP3, IMAP ...
Hmm, that's intriguing; I wasn't aware of that. Do you have a pointer to some work product? > Also, most REST implementations have a process for acquiring a token, > and then including that token in the XML message. What do you think > of tweaking the existing OpenID Authentication response so that the > RP returns a token for use in later calls? Interesting. So, you're suggesting the owner of an identity provision an API key interactively using the existing authentication mechanism, and subsequent non-interactive REST API calls would use this API key to authenticate? Or am I misunderstanding? I had considered that, and it would certainly work, but what I found unfortunate about that arrangement is that the authentication of the identity is decoupled from the API calls themselves, so the user couldn't, for example, revoke permission to use her identity with that API, since an API key would already be provisioned. Of course, the API keys could have expiration dates, but that opens up its own usability problems. I guess another way to look at it is that the API key is conceptually equivalent to a cookie used by an RP to preserve authentication state with the user agent. The difference to my mind is that, when the cookie expires, the user can reauthenticate, so an expiration of 30 or 60 minutes is probably reasonable, but when an API key expires, the user agent has no way to re-authenticate without parsing some HTML and composing a POST to the IdP, which is the arrangement I'm hoping to avoid. Adam _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
