Re: Defining how OpenID should behave with fragments in the return_to url

2009-03-25 Thread James Henstridge
On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard lshep...@facebook.com wrote:
 One crude way to do it would be to have the caller specify that they want
 the return_to args simply appended instead of integrated into the URL-
 perhaps an argument like openid.append_return_to_params=true. But that
 sounds hackish and I’d love to hear feedback on a better way to do this.

How would this interact with OpenID providers that respond via a POST
request instead of a GET?  This is something they are permitted to do
according to the spec, and may decide to do so even if the
authentication request was started with a GET if the response is large
enough.

If it helps, you could reproduce such a response with a form like:

form action=http://open.lukeshepard.com/openid_receiver.html?query#hash;
  method=post accept-charset=UTF-8
  input type=hidden name=openid.ns value=...
  ...
  input type=submit value=Submit
/form

This proposal sounds like something that will work most of the time
but fail in a number of valid cases.

It'd be nice to support the popup based authentication workflow well,
but I am not convinced that relying on this quirk is the right way to
do so.

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


Re: Defining how OpenID should behave with fragments in the return_to url

2009-03-25 Thread James Henstridge
On Thu, Mar 26, 2009 at 1:49 AM, Martin Atkins m...@degeneration.co.uk wrote:
 James Henstridge wrote:

 On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard lshep...@facebook.com
 wrote:

 One crude way to do it would be to have the caller specify that they want
 the return_to args simply appended instead of integrated into the URL-
 perhaps an argument like openid.append_return_to_params=true. But that
 sounds hackish and I’d love to hear feedback on a better way to do this.

 How would this interact with OpenID providers that respond via a POST
 request instead of a GET?  This is something they are permitted to do
 according to the spec, and may decide to do so even if the
 authentication request was started with a GET if the response is large
 enough.


 This is a good point, but it seems like again it can be worked around by
 making openid_reciever.html accept POST requests.

 Unlike the query string, this can't be done completely client side, but it
 ought to be reasonably simple to set up some kind of rewriterule or other
 indirection trick to make POST requests to openid_reciever.html actually get
 served by a non-static endpoint.

Any intermediate caches would also drop their cached versions when
they see a POST request too (assuming they follow the standards), but
I suppose it'd still be a win if the POST requests are infrequent.

This is starting to become a lot more complicated than the simple
static return_to page from the initial proposal though.


 To be honest, I'd be surprised if POST requests from OP to RP worked
 interoperably today, but the trick of using the # on the end of the
 return_to URL to signal to a supporting OP I'm trying to do this completely
 client-side, so don't do a POST request works here too.

Disallowing post responses limits the use of the more verbose
extensions (e.g. attribute exchange).  While this might be acceptable
for Luke's particular use case, it might leave it unsolved for others.
 It might be worth going back to basics and considering whether there
are other solutions.

The stated aim was to provide the best user experience possible for
running an OpenID authentication request through a pop up window and
then communicating the results back to the main window.

Luke's proposal is one possible solution, but I wouldn't want to
impose limitations on the specification if there is an alternative
that also solves the problem.

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


Re: CLARIFICATION: Is OpenID Discovery Optional?

2009-01-06 Thread James Henstridge
2009/1/7 David Fuelling sappe...@gmail.com:
 All,

 Wondering if anybody, especially the original OIDF Board and any
 contributor's to the OpenID Auth 2.0 spec could comment on this question for
 me.

 Is OpenID Discovery, as seen in section 7.3 of the Auth spec, optional?
 More specifically, is the information returned by discovery meant to be
 Authoritative for a particular OpenID or OP Endpoint, or is it merely meant
 to be Informative.

This seems like a bit of a weird question to me.  The way the OpenID
is structured, I can easily write an OpenID server that will respond
with properly signed positive assertion responses for identity URLs
that I don't control, should an RP decide to talk to it.

This won't help me impersonate anyone to an RP though because the
discovery information doesn't point to my server.  Being the link from
the identity URL to the OpenID provider, I don't see how you could
treat it as anything other than authoritative.

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


Re: Accessing Service on Behalf of the User--supported in OpenId?

2008-08-20 Thread James Henstridge
On Thu, Aug 21, 2008 at 12:49 AM, Scott Battaglia
[EMAIL PROTECTED] wrote:
 Thanks for the reply...some comments in-line!

 On Fri, Aug 15, 2008 at 6:26 AM, James Henstridge [EMAIL PROTECTED]
 wrote:

 2008/8/15 Scott Battaglia [EMAIL PROTECTED]:
   snip /
 
  1. Do you guys support accessing a service on behalf of a user.  In CAS
  we
  call this proxying on behalf of the user.  But essentially, if you're
  say, a
  portal, and you need to access the grades, you would retrieve a CAS
  proxy
  ticket and give it to the grades service which would resolve that to the
  user as well as the chain of where it came from.

 2. Use OAuth.  The portal acquires an access token to the grades
 service.  This involves sending the user to the grades service to
 authenticate (which might be done using OpenID).  The portal can then
 use the access token to request the data directly from the grades
 service.

 This seems like a more viable solution.  This is probably more of a OAuth
 user list question but I figure I'll check here first.  It doesn't look like
 OAuth does attribute exchange, is that true?  Or is there an extension we
 could use (or a standard way to add extensions).  My guess is that would
 start to get a little weird because if there's no interaction then there is
 no way for a user to approve/deny attribute exchanges unless there's a
 central decision made about attribute releases (which may work for us, but
 probably doesn't work in a general case)

OAuth really only defines two things:
1. how the consumer acquires an access token used to talk to the
service provider on behalf of the user.
2. how communication between the consumer and service provider is authenticated.

It doesn't define what the service provider's API look like, so that
part would be up to you to define.


  Some of the other stuff is more related to local SSO needs than the
  actual
  protocol, but I'll ask anyway:
  1. Do you support a method of determining whether someone has
  authenticated
  already (in CAS we call it gateway)?  For us it relies on the fact that
  you
  always point to one CAS server, which obviously doesn't need to be true
  in
  the case of OpenId.However, in the scenario where you know there is
  only
  one authenticating server, is this possible?

 If you are implementing a closed single sign-on system, you can do the
 following:
 1. Make the OpenID provider implement an identifier select endpoint.
 2. Make the OpenID provider automatically authenticate users who have
 already authenticated (perhaps just to known sites).
 3. For the relying party sites, if the user is unknown (according to
 local session cookie), begin an OpenID authentication request to the
 identifier select endpoint.  The result will include the user's
 identity.

 The system we're building would most likely include SSO, so most of this
 would already happen.  The additional thing CAS offers is that we won't
 force you to authenticate if you haven't already, but we will take advantage
 of the fact that you have if you did already (i.e. for a portal, if you
 haven't authenticated we'll just show a guest layout, but if you have, we'll
 actually display your layout).   My guess is we'll probably have to propose
 our own extension for this.



 If you are designing an open system (user can use whatever provider
 they want), I don't think there is an answer to this (which provider
 are you asking whether the user is authenticated to?).

 We're actually considering developing a two-tier system.  Locally, we'll
 still be interested in using OpenId, but we'd probably point all of our
 local apps to a central server.  Then our central server would be able to
 handle local users or delegate out to other OpenId servers.

If you're using that system, I guess you could define some kind of
OpenID extension that requests cancel the authentication request if
the user is not authenticated and combine that with an identifier
select authentication request.

The central server might also help address some of the trust issues
that exist with specifications like PAPE.


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


Re: Accessing Service on Behalf of the User--supported in OpenId?

2008-08-15 Thread James Henstridge
2008/8/15 Scott Battaglia [EMAIL PROTECTED]:
 Hi everyone,

 I'm the lead developer on the JASIG Central Authentication Service, one of
 the SSO servers that a number of higher education institutions use.
 Traditionally, CAS has used its own de-facto standard protocol (CAS1 and
 CAS2) which are similar in concept to much of OpenId 1.1.  We have a couple
 of additional things built in (and you guys have some stuff we don't as
 optional specifications).

 As part of the evolution of the CAS SSO server, we've been including support
 for additional protocols beyond CAS.  To date, we can support CAS1, CAS2,
 SAML 1.1, part of SAML2 and are an OpenID 1.1 provider (the dumb model).

 We're looking to expand CAS into the realm of federation.  We've been
 looking at SAML2 which while extremely powerful can also be very complex and
 goes against the concepts we've introduced in CAS1 and CAS2 (i.e. simplicity
 of protocol). OpenId gives us a much warmer, fuzzy feeling :-), so we're
 doing some initial analysis of utilizing OpenId 2 as our method for
 federation (in the nice boxes we've drawn on our white board it seems to
 work well).

 I just have a few questions for a comparison of the OpenId protocol vs. the
 CAS protocol that we're obvious to me. The main question is:

 1. Do you guys support accessing a service on behalf of a user.  In CAS we
 call this proxying on behalf of the user.  But essentially, if you're say, a
 portal, and you need to access the grades, you would retrieve a CAS proxy
 ticket and give it to the grades service which would resolve that to the
 user as well as the chain of where it came from.

There are a few models that can be used for this:

1. The user goes to the grades service and requests that their data
get transferred to the OpenID provider via the attribute exchange
protocol.  When they go to the portal site, the portal can request the
data from the OP, again using attribute exchange.

Of course, in this model there is no direct contact between the portal
and grades service in this model, so the portal would need some way of
verifying that the data it got was correct.  Digital signatures are
probably the answer here, but there is no standard for this yet (there
was a proposal for this a while back though).

2. Use OAuth.  The portal acquires an access token to the grades
service.  This involves sending the user to the grades service to
authenticate (which might be done using OpenID).  The portal can then
use the access token to request the data directly from the grades
service.


 Some of the other stuff is more related to local SSO needs than the actual
 protocol, but I'll ask anyway:
 1. Do you support a method of determining whether someone has authenticated
 already (in CAS we call it gateway)?  For us it relies on the fact that you
 always point to one CAS server, which obviously doesn't need to be true in
 the case of OpenId.However, in the scenario where you know there is only
 one authenticating server, is this possible?

If you are implementing a closed single sign-on system, you can do the
following:
1. Make the OpenID provider implement an identifier select endpoint.
2. Make the OpenID provider automatically authenticate users who have
already authenticated (perhaps just to known sites).
3. For the relying party sites, if the user is unknown (according to
local session cookie), begin an OpenID authentication request to the
identifier select endpoint.  The result will include the user's
identity.

If you are designing an open system (user can use whatever provider
they want), I don't think there is an answer to this (which provider
are you asking whether the user is authenticated to?).


 2. Similar to above, we support a concept of opting-out and forcing
 re-authentication.  So an application that contains SSNs may basically tell
 the authentication server, I don't care if they've authenticated already, do
 it again.

The PAPE extension would be appropriate here:

http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html

A relying party site can ask the OP to reauthenticate the user if they
were previously authenticated more than N seconds ago (N can be zero).
 Of course, there is nothing to prevent an OP from lying about
reauthenticating the user.  If that matters to you, then only accept
OpenID providers you trust.


 The last question:  We don't actually do this in CAS yet, but we've seen it
 and a few people have asked for it.  Is there a way to pass information
 along to say something like I need them to authenticate via
 username/password, or cert, or LOA2 or higher?

Again, the PAPE extension should handle this.


 Thanks for any answers you guys can provide.  We'll be continuing to do
 research into how OpenId2 fits into the CAS world, but I wanted to see if I
 could get some of these basic protocol comparison questions out of the way.


James.
___
specs mailing list
specs@openid.net

Re: Backporting the 2.0 extension mechanism to 1.1

2008-08-12 Thread James Henstridge
On Wed, Aug 13, 2008 at 3:56 AM, Martin Atkins [EMAIL PROTECTED] wrote:
 The Net::OpenID::Consumer perl library as it currently stands will not
 support PAPE in 1.1-mode messages since the openid.ns.alias mechanism
 is only used in 2.0 mode. I'd like to change this to use the 2.0 scheme
 in 1.1 (with a special case for sreg) but I'm only comfortable doing
 that if there's a specification (or errata) that explicitly allows it.

Perhaps you could do something similar to the python-openid library?

If you are writing support for a new extension, you can use the
registerNamespaceAlias(uri, tag) function from the openid.message
module.

When parsing OpenID 1.x messages (which can be determined by checking
for the absence of openid.ns), it uses these namespace aliases to map
the prefixes to URIs.  Outside of the message parsing code, you can
work purely in terms of namespace URIs, which limits the amount of
code that needs to know about 1.x vs. 2.0.

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


Re: Non-interactive logins

2008-07-15 Thread James Henstridge
On Wed, Jul 16, 2008 at 12:38 PM, Anders Feder [EMAIL PROTECTED] wrote:
 tir, 15 07 2008 kl. 21:28 -0700, skrev John Panzer:
 And of course any number of extensions could be created to obtain an
 access token via an alternate path, after which normal OAuth can be
 used.

 Sure, but isn't this equally true for OpenID?

Most OpenID RPs maintain some kind of session for the user, but that
is not required by the spec (some require OpenID auth to perform each
action).

In contrast, the whole point of OAuth is to generate an authorisation
token that can be used for machine access to a site multiple times in
the future.  The OAuth service provider might use OpenID when deciding
whether to grant an authorisation token to a client to access the site
on behalf of a particular user if appropriate.

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


Re: Google OpenID is now live

2008-04-10 Thread James Henstridge
On 10/04/2008, Vinay Gupta [EMAIL PROTECTED] wrote:
 I think that kind of misses the point. The *namespace* that google manages
 is now open for business as an OpenID provider. It's an unanticipated
 side-effect of the APIs.

 I think it's kind of a big deal, actually, in terms of how OpenID is right
 from an engineering perspective and how it can spread in unexpected ways. If
 only login were so easy.

This service seems pretty much equivalent to Simon Willison's
idproxy.net service for Yahoo accounts.

The big difference between this sort of service and actial OpenID
Provider support from Google/Yahoo is a matter of trust.

With an OP run by Google, the user needs to trust Google.  With this
OP, the user needs to trust whoever is running the OP not to
impersonate them.  Given the lack of contact information, I'd be
hesitant to use identities managed by that service and would not
recommend others rely on it.

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


Re: Google OpenID is now live

2008-04-10 Thread James Henstridge
On 10/04/2008, Brad Fitzpatrick [EMAIL PROTECTED] wrote:
 On Thu, Apr 10, 2008 at 12:40 AM, James Henstridge [EMAIL PROTECTED]
 wrote:

 
  On 10/04/2008, Vinay Gupta [EMAIL PROTECTED] wrote:
   I think that kind of misses the point. The *namespace* that google
 manages
   is now open for business as an OpenID provider. It's an unanticipated
   side-effect of the APIs.
  
   I think it's kind of a big deal, actually, in terms of how OpenID is
 right
   from an engineering perspective and how it can spread in unexpected
 ways. If
   only login were so easy.
 
  This service seems pretty much equivalent to Simon Willison's
  idproxy.net service for Yahoo accounts.
 
  The big difference between this sort of service and actial OpenID
  Provider support from Google/Yahoo is a matter of trust.
 
  With an OP run by Google, the user needs to trust Google.  With this
  OP, the user needs to trust whoever is running the OP not to
  impersonate them.  Given the lack of contact information, I'd be
  hesitant to use identities managed by that service and would not
  recommend others rely on it.

 James,

 openid-provider.appspot.com was written by a Google engineer, Ryan Barrett,
 who also did most the work (including all the initial work) on Blogger's
 OpenID support:

 References:

 http://appgallery.appspot.com/about_app?app_id=agphcHBnYWxsZXJ5chMLEgxBcHBsaWNhdGlvbnMYrwIM
 http://snarfed.org/space/2008-04-07_google_app_engine_launched
 http://snarfed.org/space/2007-12-02_openid_comments_in_blogger

Okay.  It wasn't clear who was running the service just by looking at
the URL originally posted.


 Further, App Engine apps don't process user credentials directly.  They go
 through an OpenID-like auth process with Google, who actually processes the
 email/password and tells the App Engine app that somebody logged in, at what
 email.  You can verify this yourself by looking at the form targets and HTTP
 traffic.  See:

 http://code.google.com/appengine/docs/users/

 So I'd say you can pretty much trust an openid-provider.a.com assertion that
 the person has a Google account.   But like others have said, it's not an
 official Google product.

I realise that Google's authsub service doesn't reveal a user's email
+ password to the relying site (in this case
openid-provider.appspot.com).  If you are using an OpenID provider
that I control, you are trusting me not to add a backdoor that lets me
authenticate to RPs as your identity URL.  And given the way OpenID
works, I'd have a pretty good idea of which RPs to go after.

Based on the info in the links you provided it is probably safe to
trust the site not to do these things, but it is not clear from the
information on that site alone.

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


Re: Using email address as OpenID identifier

2008-04-02 Thread James Henstridge
On 02/04/2008, Paul E. Jones [EMAIL PROTECTED] wrote:
   A solution that matches closer with what the user expects would be to
   map [EMAIL PROTECTED] to a claimed ID of mailto:[EMAIL PROTECTED].

 The average user is not going to know what mailto:; is.

The mailto: transition would be something done internally by the RP.
The RP could (and probably should) display email addresses without the
mailto:; prefix to the user.

This is similar to the way RPs store persistent XRIs as the user's
claimed ID but are encouraged to display the reassignable XRI.


   For (2), I'd suggest a solution that maps the email address to either
   directly to an OpenID endpoint (using the claimed ID as local ID), or
   to an XRDS file.  A DNS based solution seems fine here (either your
   NAPTR idea, or TXT records as suggested in replies to your post).


 NAPTR queries and transformations are straight-forward.  It's just a regular
  expression transformation from something that looks like an e-mail address
  to the real OpenID ID.

  But, again, I don't really care how it works. But, for the benefit of those
  who are not so technically capable, I believe it's got to be super, super
  trivial.  NAPTR would work extremely well, I think, and would be fast.  Any
  OpenID OP could provide an e-mail style identifier and it would certainly be
  a motivator for anybody providing e-mail service to also OpenID enable their
  subscriber's e-mail addresses.

I don't think there is a need to introduce an HTTP identity URL here.
If you're going to use an email address as an identity, then use an
email address as an identity.

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


Re: Using email address as OpenID identifier

2008-04-01 Thread James Henstridge
On 02/04/2008, Paul E. Jones [EMAIL PROTECTED] wrote:
 Folks,

 I've seen discussion here and there on the use of the e-mail address as the
 OpenID identifier.  Perhaps this one says it best:

 http://www.majordojo.com/2007/02/what-openid-needs.php

 I share many of same opinions.  If OpenID is going to be practically usable
 by the average person, we cannot require the person to remember some very
 complex identifier.  When I signed up for Yahoo's OpenID service, it
 presented me with a hideously ugly URL that looked similar to a
 base64-encoded string.  I could not begin to tell you what it was.
 Fortunately, Yahoo allowed me to define my own, friendlier name.  Still, the
 ID is not one that the average user will remember or get right.

 While the e-mail address does not have to be the one's ID, it can certainly
 serve as an alias.  Suppose, for example, that the DNS records at Yahoo
 contained the following entry:

   yahoo.com. IN NAPTR 100 10 U OpenID2
 ^(.+)@(.*)$!https://me.yahoo.com/\1!i;

 This would allow a Relaying Party to accept an e-mail address and perform a
 simple transformation to get the real URL identifier.  Of course, this
 does not mean that the existing URL or XRI identifiers are invalid, nor does
 it mean that the email address has to be a real e-mail address.  But, this
 form would certainly be far simpler for most people to deal use.

If your aim is to let people use an email address as an identifier,
there are a few questions to answer:

1. when a user enters an email address into an RP, how is the claimed
ID derived from that input?

2. given such an input, how does the RP go about discovering the
OpenID endpoint URL and local ID for that identity?

With answers to these two questions, the remainder of the protocol
should function as is.

I'm guessing (correct me if I'm wrong) that you're suggesting that
this DNS lookup be done as part of (1).  This seems like it would
cause confusion if the user's ISP changed their DNS, since the user
would see their email address as being the real identifier: not the
URL that it maps to.

A solution that matches closer with what the user expects would be to
map [EMAIL PROTECTED] to a claimed ID of mailto:[EMAIL PROTECTED].

For (2), I'd suggest a solution that maps the email address to either
directly to an OpenID endpoint (using the claimed ID as local ID), or
to an XRDS file.  A DNS based solution seems fine here (either your
NAPTR idea, or TXT records as suggested in replies to your post).

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


Re: Using email address as OpenID identifier

2008-04-01 Thread James Henstridge
On 02/04/2008, Paul E. Jones [EMAIL PROTECTED] wrote:
 Brad,

 Your point about DNS limitations is valid.  Then again, anybody who will be
 offering the open identity server is likely going to have control over their
 DNS.  Still, I'm not opposed to alternatives.

 But, since you brought up the fact that one can enter yahoo.com and get
 redirected, I checked and, indeed, several OpenID sites already accept the
 e-mail ID as a form of identification—and I can get redirected to either
 Yahoo or MyOpenID.com.  So, do some of the libraries already check for
 e-mail address forms?  It seems that perhaps they do!

What you are seeing is probably not what you expect:

 from openid.consumer.discover import discover
 claimed_id, services = discover('[EMAIL PROTECTED]')
 for service in services:
... print 'Local ID:', service.getLocalID()
... print 'Server URL:', service.server_url
...
Local ID: None
Server URL: https://open.login.yahooapis.com/openid/op/auth
 claimed_id
'http://www.yahoo.com/'

What is happening is that [EMAIL PROTECTED] is being treated as
http://[EMAIL PROTECTED]/.  As http://yahoo.com; results in an
identifier select endpoint that will work for any Yahoo user.

Note that the HTTP username isn't being used for anything here, and
you'll get the same result by just entering yahoo.com.  I wonder if
the Yahoo guys had considered this, or if it is just a happy accident?

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


Re: Problems with OpenID and TAG httpRange-14

2008-03-19 Thread James Henstridge
On 19/03/2008, Noah Slater [EMAIL PROTECTED] wrote:
 On Tue, Mar 18, 2008 at 07:54:20PM -0700, Kevin Turner wrote:
   A request for an OpenID Identifier SHALL NOT issue a 303 response.


 This is even worse and also backwards incompatible. All the OpenIDs that
  currently use 303 redirects, including mine, will all break.

  Given two backwards incompatible changes I hardly see how one which breaks
  existing OpenIDs is favourable to one which changes how some are handled.

That seems to be an argument for making no changes.


   The change you are proposing is not backwards compatible -- an RP that's
   decided your identifier is example.com/about would then decide it's
   example.com/ as soon as it upgrades to the new version, and that
   wouldn't be good for existing users.


 I think it should behove the OpenID group to actually estimate how many people
  might be using 303 redirects in conjunction with an OpenID such as I am 
 before
  concluding that the change should not be made.

  I have a sneaking suspicion that I may be the only person.

  If that is that case, I am happy to inform you that I don't mind the change.

You're okay with sites interpreting your ID differently depending on
the version of OpenID they support?  Aren't you concerned that you'll
lose access to your accounts on various RPs if your OP or the RP
upgrades?  Or do you planning to only talk to RPs that support the new
version?

I also don't think that such a decision should be based on your
assertion that you're the only one who would be affected.


   The XRDS-resolution-for-HTTP-identifiers (nee Yadis) already provides a
   mechanism to publish discovery information at a URL which does not have
   HTML content.


 Sure, but that doesn't help me and my use case.


   The code path you are are requiring the implementations to change
   (OpenID discovery and normalization) is, with the combination of
   different identifier types, protocol versions, and discovery schemes,
   already one of the most tangled chunks of code involved.  I acknowledge
   that your proposed change, in isolation, seems simple enough, but that
   code *really* doesn't need another branching condition in it.


 Arguing the complexity of the implementation is just wand waving without some
  concrete evidence to suggest that this would be a complex change.

  Most HTTP libraries should offer simple hooks into the redirect chain.

To maintain compatibility with existing versions of OpenID, RPs would
need to perform discovery, and then decide which of two identity URLs
to use based on which protocol version is negotiated.

Whatever you might say about the existing discovery mechanism, this
does seem a lot more complex, since it intermingles discovery with
protocol version negotiation.


   I appreciate the spirit of your suggestion.  It's a terrible thing to
   say oh, we follow standard X, except in the cases outlined in appendix
   B, which you will have to modify your X-implementation to be aware of.
   But, practically speaking, the use case is not compelling enough to
   overcome the cost of change.


 Again, I don't think you have provided any specifics about the cost of change.

  We don't know how many people use 303 redirects with OpenID and we don't know
  exactly how complex a change to the OpenID libraries would be.


   And it's not like you have an RP
   implementation that *almost* works except not quite because the
   libhttp-follow-redirects-
   
 and-return-the-content-and-the-final-URL-unless-the-redirect-was-a-303-in-which-case-
   return-the-intermediate-url function in your web framework is returning
   something incompatible with OpenID.  (Or, if it is, I really want to
   hear about what HTTP client implementation you're using.)


 Well, many HTTP clients provide clear hooks into redirect chain.


   I know that *you* think the semantics are clear, but the fact that
   knowledgeable people have been haggling over it for weeks on the list
   suggests that it may not be.


 Well, from my perspective it seems like eventually most people on the list
  agreed that it was an issue as outlined by my use case. In any case, the
  simplest things are often discussed at great length, if for not other reason
  than the colour of the bikeshed, so this is a non sequitur.


   So, IMHO, the best way to make this problem go away is to just say that
   303s are an invalid way of telling an RP where discovery information is.


 As I mentioned above, instead of altering how all the existing 303d OpenIDs
  (again, perhaps I am the only one using OpenID like this) are handled, you 
 would
  break them all, permanently.


   RPs will continue to work the way they do now, for backwards-compatibility
   purposes


 How are you so sure? Perhaps they will just stop working one day.


   and anyone publishing OpenID identifiers in the future will be able to 
 find a
   clear statement about it in the spec.


 This makes no sense. The current specification 

Re: Difference between 1.0 and 1.1

2008-03-12 Thread James Henstridge
On 12/03/2008, techtonik [EMAIL PROTECTED] wrote:
 So, if I understand correctly there is no way for consumer to detect which
 version - 1.0 or 1.1 is used in HTML delegation case, because delegation
 tags are the same, i.e.


 link rel=openid.server
 href=http://www.livejournal.com/openid/server.bml;
 link rel=openid.delegate
 href=http://exampleuser.livejournal.com/; so in my case
 Drupal consumer decides that either 1.0 or 1.1 version of specification is
 used and makes a request to OpenID server with openid.ns set to either
 http://openid.net/signon/1.1; or http://openid.net/signon/1.0;. But 1.1
 OpenID server doesn't know anything about openid.ns, because it was added
 only in 2.0  Therefore server fails to authenticate and this should be
 considered a bug in consumer, which should not send openid.ns at all. If
 everything above is right then where is the logic and what are the reasons
 for consumer to send openid.ns=http://openid.net/signon/1.1; at all?

OpenID 1.x messages do not contain an openid.ns field.  That field was
introduced in OpenID 2.0, and states that All messages in OpenID
Authentication 1.1 omit the openid.ns parameter.

If you are sending requests with openid.ns set to anything other than
http://specs.openid.net/auth/2.0; you are going to run into trouble.

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


Re: SREG 1.1 Request parameters

2008-02-21 Thread James Henstridge
On 21/02/2008, Enis Soztutar [EMAIL PROTECTED] wrote:
 Hi,

  As far as I understand, the distinction between sreg.required and
  sreg.optional is entirely in the responsibility of the consumer and
  there is not reason for the protocol to include this arbitrary division.
  An OP implementation will just merge the two fields and try to fill them
  as much as it can.

It is a hint from the RP about which pieces of user information it
requires.  The OP may choose to use that info when asking the user for
authorisation to send the data.

Of course, the RP needs to handle the case where it doesn't receive
some user details it asked for, possibly by getting the user to fill
them in when they return from their OP.


  I propose we merge this two fields for version 1.1. This will introduce
  another backwards compatibility rule, but I think this design will be
  better.

Introducing new features to the SREG extension seems a bit
questionable.  If you want to do things that SREG doesn't handle,
you'd be better off looking at the attribute exchange extension.

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


Re: OpenID 3.0

2008-02-03 Thread James Henstridge
On 04/02/2008, Eddy Nigg (StartCom Ltd.) [EMAIL PROTECTED] wrote:
  James Henstridge wrote:
  Of course, the OP is restricted to returning identities that it is
  authoritative for.  This is what allows any yahoo user to enter
  yahoo.com as their OpenID identifier while still letting RPs tell
  them apart.

 Right, that's what I thought...What does it have to return however?
 Is it enough to return [openid_identity] = https://somenick.domain.com/,
 [openid_claimed_id] = https://domain.com/ ?

That is possible provided that performing discovery on
https://domain.com/ gives you https://somenick.domain.com/ as the OP
local identifier and uses the given OP.

When selecting an identifier, the OP chooses both the local identifier
(openid.identifier) and claimed ID (openid.claimed_id).


  My point was that in cases where you do want to limit things to a
  single OP, it is worth considering this mode, since it does not
  require the user to enter any credentials (username or password) at
  the RP site.

 Yes, that is rather easy. Somewhat more tricky gets when you want to
 use a group of providers and ban certain providers. All doable, but not
 standardized yete.g. white/black lists.

As Kevin said, you can always apply that kind of policy at the end of
authentication process.  You can do that with either OpenID 1.x or
2.0.

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


Re: OpenID 3.0

2008-02-02 Thread James Henstridge
On 02/02/2008, Eddy Nigg (StartCom Ltd.) [EMAIL PROTECTED] wrote:
 Yes, I also wonder why the IDP can't just return the ID. As of now I think 
 it's
 two steps for this, with the RP explicit requesting it? Or am I wrong with 
 that?

When used in directed identity mode, the OP can pick the identity:


http://openid.net/specs/openid-authentication-2_0.html#responding_to_authentication

Of course, the OP is restricted to returning identities that it is
authoritative for.  This is what allows any yahoo user to enter
yahoo.com as their OpenID identifier while still letting RPs tell
them apart.

My point was that in cases where you do want to limit things to a
single OP, it is worth considering this mode, since it does not
require the user to enter any credentials (username or password) at
the RP site.

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


Re: OpenID 3.0

2008-02-01 Thread James Henstridge
On 02/02/2008, McGovern, James F (HTSC, IT)
[EMAIL PROTECTED] wrote:
 Figured I would ask if anyone is interested in brainstorming the next
 version of OpenID and how it can be used in Enterprise B2B settings and not
 solely focusing on consumerish interactions. Some things that I would like
 to see in the next version are:

 1. A discussion on how AuthZ can converge with OpenID
 2. Modeling of relationships
 3. Not allowing an OpenID to be a vector for SQL Injection and putting
 something around what it should look like

I'm not sure what there would be to say in the spec about this: SQL
injection is not party of the standard, but rather a feature of some
implementations :)

 4. A way to indicate to the relying party what level of authentication has
 occurred such as did the OP check a password, how did it validate a user.
 Without this, there is no way that a trust model could be established in a
 credible way.

The provider authentication policy extension handles half of this
already (telling you what checking the OP did).  It does not cover the
trust issue though, so without a pre-existing trust relationship there
is no reason to believe the PAP assertions.

The trust side is something that would be interesting to see addressed
in future specs.

 5. A way for OpenID relying parties to filter out Ops. In a business
 scenario, if I run the Sun employee store, I may only want the Sun OP to
 talk with me.

This is already possible with OpenID 2.0:
1. make the Sun OP provide an OP identifier URL that can be used to
initiate a directed identity request to authenticate any user of the
OP.
2. to authenticate, the Sun employee store would initiate an OpenID
request against the URL from (1) rather than asking the user to enter
an identity URL.

With this setup, the user need not know that they are using OpenID or
know what their identity URL is.

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


Re: OpenID 3.0

2008-02-01 Thread James Henstridge
On 02/02/2008, Kevin Turner [EMAIL PROTECTED] wrote:
 On Sat, 2008-02-02 at 08:51 +1100, James Henstridge wrote:
   5. A way for OpenID relying parties to filter out Ops. In a business
   scenario, if I run the Sun employee store, I may only want the Sun OP to
   talk with me.
 
  This is already possible with OpenID 2.0:
 [snip]

 This is already possible with OpenID 1.0:

 Perform discovery on the given identifier.  Compare the discovered OP
 Endpoint to those in your filter.  If you do not like what you see, do
 not proceed.

Right.  I guess I forgot about that after using directed identity for
a few cases just like this.  I'd argue that directed identity with a
fixed OP URL can provide a nicer workflow for these sort of closed
environments though:
 1. the RP need not ask for a user name, so all authentication occurs on the OP.
 2. If the user is already authenticated to the OP, the user could be
authenticated to the RP without having to enter any input (if
desired).
 3. As mentioned earlier, the user does not need to know their
identity URL (or even that they have one) -- they only need ot know
the credentials needed to log into the OP.

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


Re: OpenID 2.0 Section 9.2.1

2007-10-29 Thread James Henstridge
On 29/10/2007, John Ehn [EMAIL PROTECTED] wrote:
 I've been reviewing Draft 12, and noticed this section, which I think will
 cause problems for some systems.


 9.2.1.  Using the Realm for Return URL Verification

 OpenID providers SHOULD verify that the return_to URL specified in the
 request is an OpenID relying party endpoint. To verify a return_to URL,
 obtain the relying party endpoints for the realm by performing discovery on
 the relying party (Discovering OpenID Relying Parties). As always when
 performing discovery, the discovered URL is the URL of the last HTTP
 response, following redirects. If any redirects are followed when performing
 discovery on the realm, verification has failed. If discovery has
 successfuly completed, check to make sure that the return_to URL matches one
 of the relying party endpoints.

 A realm may contain a wildcard, and so may not be a valid URL. In that case,
 perform discovery on the URL obtained by substituting www for the wildcard
 in the realm.

 To match a return_to URL against a relying party endpoint, use the same
 rules as for matching the return_to URL against the realm, treating the
 relying party's endpoint URL as the realm. Relying party endpoint URLs MUST
 NOT contain a domain wildcard, and SHOULD be as specific as possible.

 If verification is attempted and fails, the provider SHOULD NOT send a
 positive assertion to that return_to URL.

 Providers MAY cache verified return_to URLs.

 I think it is a nice idea, however, it does not take into account situations
 where a Relying Party may not exist on the public Internet.  For instance,
 let's say I have an intranet application.  The following is true:

 The application is located on a host in my office
 My office is connected to the Internet via a NAT firewall (all internal IP
 addresses are not accessible from the Internet)
 My application uses OpenID for authentication
 A guest worker has been given permission to use my application with their
 OpenID provided by another company
 The following should happen:

 The user will attempt to log in with their OpenID
 My application will send a request to the OpenID Provider
 The Provider will attempt to perform RP discovery
 The RP discovery will fail
 The OpenID Provider rejects the authentication request
 As you can see, for this use case, OpenID would no longer be usable.

From my reading of the spec, the OP only tries to verify the return_to
value if RP discovery succeeds.  If RP discovery fails, then return_to
verification is not attempted.

In the case of an intranet RP (or any other RP that hasn't implemented
discovery), any return_to URL that matches the realm should be
acceptable.

The case where the OP SHOULD NOT return a positive assertion is if:
 1. the OP attempts RP discovery
 2. RP discovery succeeds
 3. the return_to URL is not in the list of discovered RP endpoints

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


Re: More questions about openid.ax.update_url

2007-10-22 Thread James Henstridge
On 18/10/2007, Johnny Bufu [EMAIL PROTECTED] wrote:
 Hi James,

 On 17-Oct-07, at 2:42 AM, James Henstridge wrote:

  I have a few more questions about the update_url feature of OpenID
  attribute exchange that I feel could do with answers in the
  specification.
 
  For the questions, imagine an OpenID RP with the following properties:
 
  1. The RP provides a unified login/signup workflow, so that if a user
  signs in with a previously unused OpenID a new account is created.
 
  2. The RP does not manage any user details, instead requesting them
  via attribute exchange during login, and through updates provided via
  the openid.ax.update_url protocol.

 If the RP does not store any user attributes (and requests them with
 each transaction from the OP), why does it want to be updated when
 the user changes an attribute value at their OP?

What I meant was that the RP would act as a cache for the user details
stored in the OP.

So the RP would not provide a form letting the user change their
profile details, instead advising them to make the changes at their
OP.  The changes would then be communicated back to the RP via an
update_url message.


 Maybe I'm not understanding the flow and what the RP is supposed to
 do with a new value sent to the update_url.

It'd update the cached user details stored by the RP.


  3. Some portion of users enter an OP identifier URL into the login
  page on the RP (i.e. they are using directed identity).
 
  4. The RP does not want to ask the user to authenticate twice, even if
  they are creating an account.
 
 
  With this setup, it is highly likely that the RP will send multiple
  openid.ax.update_url requests for some users.

 I believe this happens because of the incompatible RP requirements
 you listed at step 2.

Here, I meant that the RP is likely to send multiple authentication
requests with openid.ax.mode=fetch_request and openid.ax.update_url
fields, since it doesn't know that it has already asked for updates
for the particular identity.


  For standard authentication requests, the RP will know whether it has
  previously requested updates, but in the directed identity case we
  don't know what claimed ID will be picked at the time of making the
  request.  So in some cases the RP will ask for updates for an OpenID
  that they are already receiving updates for.
 
  So the question is what should an OP do if it receives multiple
  requests for updates for a particular claimed identifier with the same
  ax.update_url or realm value?  Should it treat the latest request as
  superseding the previous ones?

 If the (claimed_id, update_url) pair is the same the OP already has
 it on file and doesn't need to do anything extra when processing the
 update_url in the fetch request.

Okay, that is good to know.  It seems like a good reason not to
include a transaction ID or similar in the update_url like the
example in the specification then.

If the two requests for updates ask for different sets of attributes
(as might happen after upgrading the software on the RP), could the OP
decide to throw out the old update request, or should it send updates
for the union of the two requests?

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


Re: [OpenID] identify RP when it gets OpenID URL

2007-10-17 Thread James Henstridge
On 17/10/2007, Manger, James H [EMAIL PROTECTED] wrote:
 Other solutions:

 OPs can offer different authentication mechanisms based on the
 openid.return_to or openid.realm parameter in an authentication request.
 However, the user has less flexibility when they have to relying on OPs.

If the primary aim is just to let the user set a policy on how
carefully they should be authenticated when talking to particular RPs,
why wouldn't this alternative be appropriate?

You are trading complexity at the OP end for complexity at the
discovery/delegation end.

Or are you trying to address a slightly different problem?  Maybe one of:
 1. using an OP that is not publicly accessible for certain operations
 2. using an RP that will only authenticate people using a particular OP.

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


More questions about openid.ax.update_url

2007-10-17 Thread James Henstridge
I have a few more questions about the update_url feature of OpenID
attribute exchange that I feel could do with answers in the
specification.

For the questions, imagine an OpenID RP with the following properties:

1. The RP provides a unified login/signup workflow, so that if a user
signs in with a previously unused OpenID a new account is created.

2. The RP does not manage any user details, instead requesting them
via attribute exchange during login, and through updates provided via
the openid.ax.update_url protocol.

3. Some portion of users enter an OP identifier URL into the login
page on the RP (i.e. they are using directed identity).

4. The RP does not want to ask the user to authenticate twice, even if
they are creating an account.


With this setup, it is highly likely that the RP will send multiple
openid.ax.update_url requests for some users.

For standard authentication requests, the RP will know whether it has
previously requested updates, but in the directed identity case we
don't know what claimed ID will be picked at the time of making the
request.  So in some cases the RP will ask for updates for an OpenID
that they are already receiving updates for.

So the question is what should an OP do if it receives multiple
requests for updates for a particular claimed identifier with the same
ax.update_url or realm value?  Should it treat the latest request as
superseding the previous ones?

[I am not sure whether checking (claimed_id, realm) or (claimed_id,
ax.update_url) pairs would be more appropriate in the above].


The next question is how much information from the original OpenID
authentication request/response can the RP expect to be included in
the subsequent update responses.

If the original request was for
openid.claimed_id=http://www.jamesh.id.au/ and
openid.identity=http://example.com/jamesh, will those values be
included in future updates responses?

Looking at it from the other side, an OP implementer would want to
know how much information from the request needs to be stored in order
to satisfy future update responses.


The next one is not so much a question as an observation: As an
identity URL may change its delegation over time (possibly without the
underlying OP's knowledge), it is possible that an RP will receive
updates from an OP that is not authoritative for the claimed ID.

So in addition to checking the signature on the unsolicited OpenID
response, an RP must perform discovery on the claimed ID to verify
that the OP is correct.  I could imagine an RP missing this step when
implementing the spec.


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


Re: OpenID Trusted Authentication Extension

2007-08-31 Thread James Henstridge
On 31/08/2007, John Ehn [EMAIL PROTECTED] wrote:
 Well, I've slept on it.  I think we have a difference in philosophy.

 The other Extesions - AX, Simple Registration, etc. - follow the same data
 flow methodology:

 RP - UA - OP
 RP - UA - OP

With my proposed workflow, it'd be going through the UA too.

The checkid_setup request and id_res response uses indirect
communication, so those calls do go through the user agent.  I did not
specify this explicitly in my previous email because it is implied.

So the workflow would look something like this if the data provider
needs to authenticate the user:

DC - UA - DP - UA - OP
DC - UA - DP - UA - OP

In the communication between DC and DP, the DC is the RP and the DP is
the OP.  In communication between the DP and OP, the DP is the RP and
the OP is the OP.


 I believe I'm sticking to the same principles in my spec.  We are doing the
 very same thing when we collect the authentication key (see above).  We are
 even doing the very same thing when we have the sites authenticate with each
 other.  It's just we have a non-human operating the User Agent.  In this
 case, the RP is the destination site, the UA is the client site:

 RP - UA - OP
 RP - UA - OP

You still want the user involved in the granting of an authentication
token though, right?  Trying to replace the UA in the authentication
workflow is quite a big change, and limits what the OP can do.


 I think this fits well with what people expect.  I also have no problem with
 having OPs incrementally improve their systems to make them compatible with
 new extensions.  Since there will (eventually) be far more RPs out there
 than OPs, I think it's reasonable for them to support the bulk of the
 extension implementation.

With your proposal, the user's OP needs to implement an extension.
This brings up a few questions:

1. Should the data provider only let users register if their OP
implements the extension?  What is the benefit to the data provider in
enforcing such an extension?

2. If only some users' OPs implement the extension, can the data
consumer rely on the protocol at all?

In contrast, both the data provider and consumer have an incentive to
implement an extension for auth token transfer, so a spec that only
requires modifications to those parties seems easier to roll out.
What do you think?


[snip]
 Although your implementation is sound, and I like a lot of the ideas, they
 shift a lot of the responsibility to the party receiving the authentication
 request.  I'm not sure I like the idea of having the burden of implementing
 both an API and a special pseudo-OP.  This also removes the power of having
 a single Identity management interface at the OP, meaning the user will have
 to log on to the destination site to invalidate the token.  What if the user
 has 50 of these API connections set up?  That's 50 sites to visit in order
 to manage these tokens.

I guess that is a concern.  But how often do you expect the data
provider to check the user's OP to see if the token is still valid?
If it doesn't check often, then revoking the token at the OP level
might take a while to take effect.

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


Re: OpenID Trusted Authentication Extension

2007-08-30 Thread James Henstridge
On 26/08/07, John Ehn [EMAIL PROTECTED] wrote:
 I have created a draft of a new specification that I think will help to fill
 a gap in OpenID functionality.

 What appears to be a newer productivity feature of many websites is the
 ability to import and utilize information from other sites.  For instance,
 Basecamp provides an API that allows other systems to access user data.
 This is a great feature, but it currently cannot be done with OpenID, due to
 the dependence on end-user interaction during the authentication process.

 The Trusted Authentication Extension provides for the ability for an OpenID
 Consumer to log in to another OpenID Consumer without user interaction.  The
 end user will be able to create a trusted connection between two OpenID
 enabled sites, which will allow a client site to access a destination site
 using the end user's Identity.

 Please provide your comments and feedback, as they are most appreciated.

 http://extremeswank.com/openid_trusted_auth.html

I think things would be a bit clearer if you made the data provider
into a form of OpenID Provider.

I think it helps to first consider the case where the data provider is
not an OpenID Relying party but instead has its own user account
database.

If the site acted as an OpenID provider, it would be pretty simple to
use an extension to negotiate an auth token to acess data for the
user.  Simply start an OpenID authentication request, including some
field stating that you want access to data.  The provider would then
include an authentication token in the response that could be used to
access the web services.


Now lets consider the case where the data provider identifies users by
an OpenID.  What would happen if the data provider continued to
implement an OP, and the data consumer started an OpenID
authentication request with it using the user's data provider.

This would let us use the same sort of OpenID extension to negotiate
the auth token.  The data provider could even turn around and perform
its own authentication request to verify that the user is who they say
they are, since it received the identity URL from the data consumer.

So the full workflow might go like this:

DC: Data Consumer
DP: Data Provider
OP: User's OpenID Provider

1. DC sends checkid_setup request to DP for user's identity URL, with
an extension asking to negotiate an auth token.
2. DP initiates OpenID authentication for user's identity URL
3. OP verifies user's identity and sends idres reply to DP.
4. DP sends idres reply to DC, including the auth token as an
extension in the response.

This seems to give similar results to your protocol while introducing
fewer new concepts.  What do you think?

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


Re: OpenID Trusted Authentication Extension

2007-08-30 Thread James Henstridge
On 30/08/2007, John Ehn [EMAIL PROTECTED] wrote:
 James,

 Sorry, but I'm having problems following the flow.  It seems like an
 interesting idea, though.  Can you provide with a little more information on
 how these components would interact?

Okay.  The basic idea was that instead of creating a special protocol
for two OpenID relying parties to communicate with each other was for
the web services data provider to act as an OpenID provider.

So, lets assume that the data consumer wants an auth token for the
user identified by http://user.identifier.url.  With normal OpenID
authentication, you'd perform discovery to find the user's OpenID
provider.  To request an auth token though we need to talk to the data
provider, so instead we skip discovery and perform an authentication
request to the data provider's endpoint.  The parameters might look
something like this:

 * openid.mode = checkid_setup
 * openid.claimed_id = http://user.identifier.url
 * openid.identity = http://user.identifier.url
 * openid.return_to = http://data.consumer/...
 * openid.ns.auth = ...
 * (additional parameters related to the auth token request)

The data provider would then decide whether to grant the auth token
(possibly by performing OpenID authentication against
http://user.identifier.url, and/or asking the user), then send a
response back like:

 * openid.mode = id_res
 * openid.claimed_id = http://user.identifier.url
 * openid.identity = http://user.identifier.url
 * openid.return_to = http://data.consumer/...
 * openid.ns.auth = ...
 * openid.auth.token = ...
 * openid.auth.secret = ...

The data consumer knows that the request came from the data provider
due to the signature on the OpenID response.  The data provider knows
which user to create the token for because it was present in the
OpenID request.  The data provider can verify that the web browser
user is that user because control gets transferred to the data
provider during the authentication process.

This all assumes that the data consumer has already authenticated the
user, so knows which identity URL to request a token for from the data
provider.

 I was really trying to keep everything dumb and simple.  The concept I was
 going for was piggy-back on OpenID, but include a way to programmatically
 log on to the OpenID Provider.  The problem I saw with OpenID was that
 there are about a million different ways to authenticate with an OpenID
 Provider, from HTML forms to digital certificates.  Most require the User
 Agent to be a web browser.  However, there is no standard way to just pass a
 credential that can prove that you are who you say you are.

Well, OpenID authentication requests are designed to let the OP
perform whatever checking they want before sending a response.  So by
making the data provider act as an OP, it has the same freedom
(including the freedom to issue its own OpenID authentication request
to the user's actual OP).

 I was trying to solve the problem by coming up with an automatable (if
 that's a word) way to authenticate with an OpenID Provider.  If we have
 that, there's no need to pass around a special token, because we can just
 use standard OpenID authentication if we want to log on to another system.
 So, I proposed just having the Consumer get a key from the OpenID Provider
 that it can use to automatically authenticate with the Provider in the
 future.  The key is passed through the user when it's granted, because you
 need the user to approve the whole thing anyway.

I think that this makes things more complicated than need be.  If you
want an auth token from the data provider it seems better to ask the
data provider for the key directly, giving it the chance to
authenticate the user before responding.

This also has the benefit that it does not require any special
features from the user's OP -- the extension is purely concerned with
the interaction between data consumer and provider.


 I don't expect this extension to fix all problems.  It's only intended to
 solve a specific use case (website to website info sharing).  I am working
 on two additional extensions which will solve the other problems I see:

Sure.  I doubt my suggested workflow would help with those use cases
either (at least without some additional components).

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


Re: OpenID Attribute Exchange Protocol questions

2007-07-10 Thread James Henstridge
[replying to myself]

On 10/07/07, James Henstridge [EMAIL PROTECTED] wrote:
 The only real constraint the authentication spec places on the RP is
 that it maintain the association for the duration of an OpenID
 authentication request.

 With unsolicited response though, there is no prior request that tells
 us the RP is holding a particular association _right now_.

I just realised another difference when working with unsolicited responses.

With a normal OpenID authentication request the RP picks an
association handle, so we know the RP believes it is valid.  However,
the OP can use a private association handle in the response if it
considers the handle from the request to be invalid.  So the OpenID
authentication spec does not seem to require either the RP or OP to
store an association for longer than ~ one request.

In contrast, if a previously established association is used in an
unsolicited response there doesn't seem to be any way the RP can tell
the OP that it has lost the handle.

Given that there doesn't seem to be any way to recover from this
situation, it seems like private associations are the only sane option
for unsolicited responses.

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


Re: OpenID Attribute Exchange Protocol questions

2007-07-10 Thread James Henstridge
On 10/07/07, Dick Hardt [EMAIL PROTECTED] wrote:
  Given that there doesn't seem to be any way to recover from this
  situation, it seems like private associations are the only sane option
  for unsolicited responses.

 An update message would require direct verification and not use an
 association. Associations are set by the RP, and in this case, the OP
 is initiating the conversation. I might be missing something, but I
 don't see how you can reliably use an association.

That was the conclusion that I came to.

I was replying to Johnny's statement that the OP knows the expiry time
of the association handles it stores so could use a previously
negotiated handle in the unsolicited response.

I think it would be good to include a statement to this effect in the
specification so that implementers don't have to work this out for
themselves (and maybe get it wrong).

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


Re: OpenID Attribute Exchange Protocol questions

2007-07-06 Thread James Henstridge
On 06/07/07, Johnny Bufu [EMAIL PROTECTED] wrote:

 On 6-Jul-07, at 12:37 AM, James Henstridge wrote:
  My question about the transaction ID in the update URL still stands:
  won't a positive assertion response include openid.identifier and
  openid.claimed_id, which should be enough for the RP to match up the
  response?  Or do you expect the OP to not record the claimed
  identifier from the original authentication request?

 There is a use case for OpenID (though not very well defined) where
 the OP could send a positive assertion without identity / claimed_id
 fields (e.g. if the RP only requests the zipcode). For something like
 this, the RP may (note the lowercase may in the AX spec as well) add
 whatever identifying information it needs (not necessarily for a user
 id / account).

Fair enough.  I had not considered that case.


  I think my question about what association handle to use for the
  unsolicited response is adequately covered by the rules in section
  11.4 of the OpenID Authentication spec: the OP could choose to use the
  association from the original authentication request (if it is still
  valid), or create a new private association handle.

 Yes, the update uses the signature mechanism in the underlying OpenID
 message.

  In either case, it should be ready to answer a check_authentication
  request.

 Not entirely; the OP MUST NOT honor check_authentication requests for
 shared associations (this would allow a type of attack).

Okay.  In that case it sounds like it would be best practice to
generate a private association handle for each unsolicited response
since there is no guarantee that the RP has kept hold of its
association handle, so may not be able to verify the update if a
pre-existing handle is used.

Would that be appropriate to include in the spec or some best
practices document?


  1. The RP requests my phone and fax numbers in an OpenID
  authentication request:
 openid.ns.ax=http://openid.net/srv/ax/1.0
 openid.ax.mode=fetch_request
 openid.ax.type.phone=http://example.com/phone
 openid.ax.type.fax=http://example.com/fax
  [...]
  3. At some later date, my OP sends an unsolicitated authentication
  response containing the following data:
 openid.ns.ax=http://openid.net/srv/ax/1.0
 openid.ax.mode=fetch_response
 openid.ax.type.phone=http://example.com/phone
 openid.ax.value.phone=555-2345
 openid.ax.update_url=http://relying-party/...
 
  How should the RP handle this update?  According to the draft spec, I
  can think of two possibilities based on how updated data is
  interpreted?
  1. the user has changed their phone number
  2. the user has changed their phone number and removed their fax
  number.

 I don't think it's implied anywhere (or a good design) to keep state
 between the original request and subsequent updates. So the RP cannot
 infer the 'removed' statement just because an update did not contain
 an attribute that was part of the original exchange.

 The update message is a fetch response, so I think it should be
 interpreted as such by the RP: the user has a new phone number.
 Then the RP can decide what it wants to do with the new value, as if
 it had requested the same attributes again.

Thank you for the clarification.  It seems that an OP will get the
most consistent results if it always sends all attributes in an update
then, so it doesn't need to track whether intermediate updates failed
(or track exactly which attributes were changed).


 To indicate that the user has deleted an attribute, the count=0
 mechanism can be used:

  An openid.ax.count.alias with a value of 0 together with its
  corresponding openid.ax.type.alias field MAY be included to
  explicitly state that no values are provided for an attribute.

It might be worth demonstrating this in the example from section 5.2
then.  Currently it reads:
openid.ax.type.gender=http://example.com/schema/gender
...
openid.ax.value.gender=

If this is a case where the user has not given their gender it should
perhaps use openid.ax.count.gender=0 instead.

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


OpenID Attribute Exchange Protocol questions

2007-07-04 Thread James Henstridge
Hi,

I was looking at the attribute exchange protocol spec (draft 5), and
had a few questions about it:

1. I noticed a few typos in the examples.  In section 5.1, it gives an
example of a fetch_request request reading:

openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ns.ax=fetch_request
...

It uses openid.ns.ax twice.  It looks like the second occurrence
should be openid.ax.mode.  The same typo appears in sections 5.2 and
6.1.

2. The spec seems to omit details of how messages should be sent to
openid.ax.update_url.  In particular:

* What format should the message take?  Should the OP just send a
request with the openid.ax.* values?  Or should it be a full id_res
response?

* The spec says that the RP may include transaction information in the
update_url to link the update to a particular identity URL.  I guess
this only makes sense if we aren't sending a full id_res response,
since in that case the identity URL would be included.

* How does the RP verify that posts to its update_url came from the OP
and not some other party who got hold of/guessed update_url?  If we
are using an id_res response, then this'd be handled by the signature.

If we sign the response, it brings up the second question: what do we
use as an association handle?  Can we use any available association
handle, or would it be better to treat it as a dumb mode response
and require the RP to do a check_authentication request to verify the
data?

If we aren't sending a full id_res response to the RP, it seems that
the only security is in the secrecy of the update_url, which seems
strange given the use of cryptographically signed messages in other
parts of OpenID.

* The spec seems to indicate that only the changed data should be sent
in the update response.  How would I notify the RP about the absence
of an attribute?  The closest I could come up with was to use count=0:

openid.ax.type.foo=http://example.com/foo
openid.ax.count.foo=0

It would be good to document the preferred way of doing this, since I
could imagine an RP misinterpreting such a response (especially if the
attribute is usually single valued).


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