Re: Non-interactive logins

2008-07-15 Thread John Panzer

Anders Feder wrote:

If I'm not mistaken, OAuth requires the user to approve the
authentication request in her browser, which is an interactive action.
This is true, but this only needs to be done when obtaining an access 
token, which can be used potentially forever without further interaction 
from the user.

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.

Joseph Holsten pointed me to Appendix A of the OAuth specification for
an example. In step A.3, The Consumer redirects Jane’s browser to the
Service Provider User Authorization URL to obtain Jane’s approval for
accessing her private photos.

Also, OAuth appears to be more about authorization (to access a remote
resource) than about authentication.

Is there any way to operate either OpenID or OAuth entirely

tir, 15 07 2008 kl. 08:38 -0700, skrev Scott Kveton:

Hi Anders,

You might want to check out OAuth ... it was developed for just such a

- Scott

On Tue, Jul 15, 2008 at 4:20 AM, Anders Feder [EMAIL PROTECTED] wrote:


There have been some discussion over the years about using OpenID for
non-interactive logins. Can someone kindly tell me what the status is of
this feature? In particular login from non-browser applications - is
this currently possible (e.g. using client certificate authentication)?


specs mailing list


specs mailing list

specs mailing list

Re: Google OpenID is now live

2008-04-09 Thread John Panzer

Any sufficiently advanced web site system is indistinguishable from an OP.

Or, rather, can be turned into an OP. :)

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


Vinay Gupta - Designer, Hexayurt Project - an excellent public domain 
refugee shelter system
Gizmo Project VOIP: 775-743-1851 (usually works!)
Cell: Iceland (+354) 869-4605   
 Skype/Gizmo/Gtalk: hexayurt 
People with courage and character always seem sinister to the rest
  Herman Hesse

On Apr 9, 2008, at 7:45 PM, John Ehn wrote:
I agree.  I think this is an excellent technology demonstration, but 
it is a third-party, not Google, that is enabling the ID.

2008/4/9 Immad Akhund [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:

When Google eventually does make a proper OpenID provider all the
OpenIDs provided by would not match.

Would get very confusing apart from advanced users that
understand the distinction.


On Wed, Apr 9, 2008 at 12:49 PM, Paul Madsen

I expect Google might have a (legal) opinion on
characterizing this
application as 'Google OpenID'

I think I'll wait for Google itself to enable my Gmail as an


Vinay Gupta wrote:

 Somebody used their app hosting service and implemented an

 That kind of changes things, doesn't it?


 Vinay Gupta - Designer, Hexayurt Project - an excellent
public domain
 refugee shelter system
 Gizmo Project VOIP: 775-743-1851 (usually works!)
 Cell: Iceland (+354) 869-4605
  Skype/Gizmo/Gtalk: hexayurt
 People with courage and character always seem sinister to
the rest
   Herman Hesse

 specs mailing list

 No virus found in this incoming message.
 Checked by AVG.
 Version: 7.5.519 / Virus Database: 269.22.9/1365 - Release
Date: 4/8/2008 7:30 AM

Paul Madsene:paulmadsen @

specs mailing list

Cell: +1 617 460 7271

Skype: i.akhund

Clickpass, CTO
specs mailing list

specs mailing list

specs mailing list

specs mailing list

Re: OpenId as API authentication method

2007-07-27 Thread John Panzer
You should probably check out OAuth:, and its draft spec  

Eran Hammer-Lahav wrote:

I am not sure if this belongs in the spec list, but I'll give it a try.


I would like to suggest adding some text to section 11.1 (or anywhere 
else that's appropriate) that will provide guidelines for using OpenID 
in a scenario where the OpenID RP is not the site the user is actually 
using. The OpenID specification is written with some bias towards 
implementation in a website environment which is the most common use. 
My aim is to use OpenID as the authentication method for establishing 
API sessions. I am building a web service where the client (any user 
of the API) requests to create a session token which can then be used 
to bypass authentication for a certain period of time (nothing new here).


The API with HTTP Basic auth it looks something like: - with the plaintext username 
and password in the HTTP header, returns an XML reply with a session token


Each user will have a local username and password. I was trying to 
avoid it at first but with the current state of OpenID, it might cause 
problems as some OP are unreliable and users can end up locked out if 
their only access is with the one OpenID they setup their access with. 
The plan is to provide an OP for local users (so that any local user 
is also an OpenID), and to also allow users to associate any other 
OpenID with their account. Once a user adds another OpenID to their 
account, they can use that to create a session via:


For example, a USER logs into a WEBSITE which is built on top of a web 
SERVICE. The SERVICE requires OpenID authentication (the SERVICE is 
the RP). The USER login request is sent via AJAX to the SERVICE with a 
return_to URL able to capture the OP reply and send it back to the 
SERVICE. The SERVICE reply to the AJAX code with the checkid_immediate 
URL. The AJAX code calls the checkid_immediate given and captures the 
redirection reply. The AJAX code calls a second SERVICE API call 
providing the OP reply to the checkid_immediate request. The SERVICE 
validates the reply and answers with a SERVICE session. The AJAX code 
the stores the session id in a cookie and uses it for other API calls.


The same logic can be used with checkid_setup and a server side API 
call. The USER is redirected by the AJAX script to the checkid_setup 
URL received from the initiate API call. The user signs-in and is 
redirected back to the WEBSITE client_side_capture page with the 
OpenID query parameters. The WEBSITE server page client_side_capture 
receives the request, calls the SERVICE validate API, and redirects 
the USER back to the WEBSITE with the session cookie.


This voids the first step in section 11.1 since the RP receives the OP 
reply via an API call that is not the same as the return-to URL. In 
order to keep the transaction secure, I have added another signature 
to the return_to parameter. This way when the WEBSITE returns the OP 
reply to the API validate call, the SERVICE can make sure that the 
original return_to was created by it, and not by the WEBSITE. The 
normal openid.sig signature will make sure the OP reply is valid for 
the entire input. This is the an example API call and reply:


API call:


API reply: 


Given the increasing focus on web 

Re: Identifier recycling write-up on the wiki

2007-06-20 Thread John Panzer
Chris Drake wrote:
 Hi Josh,

 You've got 6 points under the use cases, but it's really just 1 use
 case, and then 5 consequences recycling.

 Is there room on your Wiki for opposition?  It's only going to take
 one screwup and an angry victim someplace and the whole recycling
 issue could bankrupt someone in the prevailing identity theft

 Why would any responsible Identity provider want to give a past
 identity to a new person, and why would we want to encourage this
 misbehavior by supporting it ?

Two easy answers:
1. Namespace exhaustion.  AOL, Yahoo, others have this issue today.  All 
the good short identifiers are taken and people want them; some of them 
have been 'dead' for years; market forces are important here.
2. WIPO + domain name disputes =  they may not have a choice.  This is 
really a global version of #1.

John Panzer

specs mailing list

Re: Specifying identifier recycling

2007-05-30 Thread John Panzer
At some point, the weak link will be humans trying to disambiguate from (or  I don't think there's a big difference 
between the two in that context, and I don't think that OID2 needs to 
solve this more deeply than allowing unique-URL.  But would this be an 
additional requirement placed on OPs?

   (Query:  I assume a 302 redirect from to will work?)

Has there been a discussion about an extension to map to/from i-numbers 
via AX?  If there were a generic attribute you could stuff an i-number 
or a hash of an internal ID in there to help solve the disambiguation 
problem.  Alternatively it'd be nice to have a way to ask when the 
account was created, if the OP is amenable.



specs mailing list

Re: Proposal for Recycling Identifiers in OpenID 2.0

2007-05-14 Thread John Panzer

Johannes Ernst wrote:

  On May 14, 2007, at 9:12, Dick Hardt wrote:

The issue you bring up is a separate issue then the motivation for
recycling identifiers by large OPs.

What I'm saying is a superset of the issue discussed so far that  
ought to use the same technical solution because the problem is the  
same: "X used identifier Y, and now Z controls Y. What now?"

Your point is how does a user transfer from one identifier to another.

While related, that's not the issue I was talking about.

But you are right in that all of those problems should be solved at  
the same time.

The issue at hand is the scarcity of namespace.

-- Dick


Absolutely. :)

Can some of these issues be solved via best practices? For example:

1. If you ever get a 410 Gone response from identifier Y, immediately
decouple X from Y -- mark account as inactive at least.
2. Try to ping known accounts for 410's at least once a year. If you
see one, go to step #1.
3. If no ping, and no login from Y for over a year, treat account as
inactive when Y attempts to log in again.
4. Inactive accounts require out of band procedures for recovering data
or transferring to a new OpenID identifier (equivalent to password

And on the provider side:
1. When you deactivate an account, make the OpenID return 410 Gone for
a minimum of two years.
2. Notify customers that they must transfer or shut down all services
using the identifier before the de-activation.
3. Recycle identifiers only after the full two year period has elapsed.

Also, we may want to consider:
1. When you see a 301 Permanently Moved response for Y, follow it and
update your local identifier keys.(*)

1. When a customer wants to transfer identifiers, use a 301 Permanently
Moved response for the old identifier for a minimum of one year.
2. After one year, respond with 410 Permanently Gone for a minimum of
one year.

These are straw men, feel free to knock them down.

(*) May conflict with other forces, such as SEO. 

System Architect

specs mailing list

Re: HTTP Authentication Bindings for two-party OpenID Authentication

2007-03-31 Thread 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 

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
specs mailing list

Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers

2006-10-20 Thread John Panzer

Kaliya *
wrote on 10/20/2006, 11:57 AM:

I think it is a terrible idea.
1) If you put something out into the market that looks like an e-mail
it will be used like an e-mail. I have personal experience with this. 
I had a AIM handle for the Mac part of the universe [EMAIL PROTECTED] (it was not an e-mail
address) but because it looked like one people used it like one and I
basically had to go to .mac and pay for an account so that the wires
did not cross.
This came out of the
discussions we have about a smooth migration path for our users at
AOL. In our case the [EMAIL PROTECTED] nickname is also a resolvable
email address, though it may not be the primary mail account of the
user. I'd suggest that as a best practice, anywhere that a
[EMAIL PROTECTED] nickname is used, it should also be a resolvable email
address. And there should always be an option to not use something
that looks like an email address.
2) I think OpenID is new and needs a
new way to identify folks. And it is our job to teach people about this
new way. Lots of services give people homepages within their
spaces...myspace, AIMpages etc. so they can use those URL's if they
don't have one yet they can get one. 
There's a bootstrapping
problem here. It's very, very hard to promote the use of something
that requires a more complex login flow to replace something that is
very simple (albeit limited and in its own silo). How can we cross
this chasm? Our suggestion is to support existing practice of
[EMAIL PROTECTED] in a standard way, while being open to new practices.
Once we can support both we can gain experience and start gradually
migrating people over to the new world. At least that's my take.

System Architect

specs mailing list