OpenID Auth 2.0 and user-agent neutrality (or, OpenID with REST/SOAP)

Dick Hardt dick at sxip.com
Sun Nov 19 23:40:49 UTC 2006


On 19-Nov-06, at 3:08 PM, Adam Nelson wrote:

>> 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?

It was the direction a number of people in the HTTP-AUTH and DIX list  
were looking at going. Have not heard of an updated status since the  
last IETF, sorry.

>
>> 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?

You are understanding.

> 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.

Note that revocations are challenging to implement. :-)

>
> 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.

Unless I am missing something, the user needs to be part of the  
process of generating a token regardless.

Will you be at IIW? This would be a great session there.

-- Dick




More information about the specs mailing list