Re: HTTP Authentication Bindings for "two-party" OpenID Authentication

[Julian Reschke]

John Panzer schrieb:
> ...
> Our Atom service currently provides the standard Allow: header to tell a 
> client what methods are allowed for a given URI + authorization 
> context.  The set of allowed methods changes depending on authorization 
> or lack thereof.
> ...

Hm. I'm not sure this is a good idea. HTTP distinguishes between 405 Not 
Allowed and 401 Auth required or403 Forbidden.

I think the Allow header should list those methods which will not cause 
a 405 to be returned, so authorization is a complete orthogonal issue.

Best regards, Julian


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: HTTP Authentication Bindings for "two-party" OpenID Authentication

[Johannes Ernst]

On Mar 31, 2007, at 18:33, John Panzer wrote:


But there's no (standard) way to tell
whether a particular URI + method requires authorization without just
trying it.


I've long advocated "marking" URLs with Yadis meta-data for that  
purpose, and my understanding is that OpenID Auth 2.0 will be the  
first step in that direction.



Johannes Ernst
NetMesh Inc.





 http://netmesh.info/jernst

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: HTTP Authentication Bindings for "two-party" OpenID Authentication

[John Panzer]

Martin Atkins wrote:

>...
>The obvious approach is to specify a way to do DH associations over an 
>HTTP authentication protocol. However, it's not clear to me how to do a 
>multi-stage authentication handshake efficiently over HTTP auth, since 
>HTTP authentication is based around sending the request, getting back a 
>401 Unauthorized response and then repeating the request in its entirety 
>with appropriate authentication credentials.
>  
>
A client can send an Authorization: header with any request, if it has 
prior knowledge of what scheme(s) the server will support and/or whether 
a given URI is protected. 

A server can provide a WWW-Authenticate: header on any request (say, 
HEAD or OPTIONS) and a client can peek at it to see what authentication 
schemes the server supports.  But there's no (standard) way to tell 
whether a particular URI + method requires authorization without just 
trying it.  Services such as GData get around this by documenting which 
URIs and which methods require what type of authorization; could that be 
sufficient?

Our Atom service currently provides the standard Allow: header to tell a 
client what methods are allowed for a given URI + authorization 
context.  The set of allowed methods changes depending on authorization 
or lack thereof.

-- 
John Panzer
System Architect
http://abstractioneer.org
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

HTTP Authentication Bindings for "two-party" OpenID Authentication

[Martin Atkins]

OpenID is currently only useful for three-party authentication where an 
end user (usually a human) is logging in to an RP with the help of an 
OpenID provider.

However, we do not have a solution for a software agent representing 
itself. Software agents don't need an OpenID Provider in the same sense 
as a human does because they can fill the role of the OpenID Provider 
themselves.

A long time ago I posted a proposal where HTTP Authentication is used as 
a transport for this sort of two-party OpenID Authentication:

 

As noted on the wiki page, this is not intended to help non-human agents 
log into traditional RPs (e.g. websites) but rather to be used with 
specialized protocols where one non-human agent needs to talk directly 
to an RP without a user present.

The main problem people had with this at the time was the use of dumb 
mode, due to its vulnerability to MitM-type attacks. I would like a 
two-party authentication protocol like this for use in several 
machine-to-machine protocols I'm designing[1], but I'm reluctant to 
reference it right now while I know people (quite rightly!) have 
reservations about the security of it.

The obvious approach is to specify a way to do DH associations over an 
HTTP authentication protocol. However, it's not clear to me how to do a 
multi-stage authentication handshake efficiently over HTTP auth, since 
HTTP authentication is based around sending the request, getting back a 
401 Unauthorized response and then repeating the request in its entirety 
with appropriate authentication credentials.

I'm told that the Negotiate authentication scheme for Kerberos does this 
by retaining the request as state on the server and having the 
intermediate requests and responses contain no body, but this doesn't 
really seem in the spirit of HTTP.

I'd be interested in any insight that others may have to offer.


-

[1] My hope is that dependent protocols will be able to use 
interchangably either three-party request authentication via "OpenID 
Exchange"[2] or two-party authentication via this specification, so that 
protocols like "Send A Message"[3] will be able to work in both modes.

[2] http://openid.net/wiki/index.php/OpenID_Exchange_1.0

[3] http://openid.net/wiki/index.php/Send_A_Message_Protocol

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs