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

2009-03-25 Thread Martin Atkins

James Henstridge wrote:

On Wed, Mar 25, 2009 at 3:33 AM, Luke Shepard 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

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.

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.

specs mailing list

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

2009-03-24 Thread Martin Atkins

This looks similar in principle to the AJAX-ish (though not really 
AJAX at all) mode of OpenID that was in the early demos but no-one 
actually seems to have implemented in practice. The trick there was to 
do the OP dance in a hidden iframe and have the return_to page 
communicate with the outer page in much the same way as the popup does.

However, the optimization of doing it with the fragment identifier is 

My first concern was backward compatibility, but it actually looks like 
we get back-compat by accident as long as openid_reciever.html is able 
to actually process the query string if it's present.

Here's a strawman:

* If the return_to URL ends with a # character, a supporting OP (or an 
OP that's doing this by accident) should make the return_to URL by 
appending the ? after the # and then adding the query string arguments 
as normal.

* The non-fragment part of the URL MUST support having the arguments 
passed in the *real* query string. In this case, the fragment part 
should be ignored and is likely to be the empty string anyway.

This allows OPs that don't work in the way you suggest to still work, 
albeit with worse UI performance due to the extra round-trip that will 
inevitably be generated.

As far as I can tell, your openid_reciever.html can still be a static 
file in the query string case, becausee most existing web servers will 
accept and silently drop query string arguments on URLs that address 
static files, and the full URL should be available client side in 
docment.location to allow you to retrieve the query string.

It'd be good to see how more existing OPs behave when presented with a 
return_to URL that ends with a #. Having MyOpenID fail is a show-stopper 
for the above approach IMHO, but hopefully they will fix their 
implementation if they are the only one broken.

(I've quite deliberately said *ends with* rather than *contains* a # 
here, because that's a simpler thing to catch for folks who will need to 
fight their local URI-mangling library in order to implement this, which 
I assume applies to MySpace -- I presume that their correct behavior 
came for free with the .NET System.Net.Uri class.)

Luke Shepard wrote:


I've noticed an ambiguity with the way URLs are handled that exists in the 
current spec. I'm hoping we can resolve it for OpenID 2.1.

When we move the OpenID transaction into a popup window, we need a way for the 
popup to communicate back with the parent. The way to do this is to set a 
return_to URL that, when loaded, reads the parameters and communicates with the 
parent window somehow.

Here's a description of a technique:

A simple way to do this is to have a simple receiver. The response will append 
query parameters:

However, there is a small performance problem with this approach. The user will 
see a blank-looking popup for a moment while the server processes the OpenID 
arguments. An optimization is to put up a simple, cacheable static HTML file 
that chucks the OpenID params back to the parent frame. The parent can then 
provide some visual feedback to the user while it sends the OpenID parameters 
off for processing. This results in a snappier experience.

If the static HTML file has no parameters and sends out long-lived cache 
headers, then the response won't even trigger a server load, and the whole 
process can appear faster to the user. In this case, the response would look 
like this:

Note that the hash appears instead of a question-mark. That tells the browser 
that it doesn't need to load an extra file, and it can save perhaps a quarter 
or half second of latency for the user on average.

Okay, so the point is that different OpenID providers currently interpret the 
hash differently. I think we should explicitly define a behavior that makes 
sense and accomodates the above suggestion. Here's how they currently behave.

When given a return_to of

MyOpenID: fails outright - invalid return_to

By the URL spec, Myspace is technically correct and Google/Yahoo are wrong. But the 
correct way doesn't allow the performance optimization listed above. I'd like 
to see a way to accommodate the hash url.

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 

Re: Request for consideration of AX 2.0 Working Group Charter Proposal

2009-01-27 Thread Martin Atkins

Dick Hardt wrote:
I'd prefer to narrow the scope of the WG and keep it focussed on a small 
number of goals.

A separate WG on SREG would be preferred, but I think it is a disservice 
to the community to have two specs having such significant overlap.
Choice in this case leads to confusion and reluctance to invest. The 
challenge is that those with an investment in SREG now have a propensity 
to see it continue on even though intellectually they can see the 
advantage of a unified spec.

fwiw: I am in an off-site most of this week and won't be able to engage 
significantly until next week.

I agree that having both is not ideal, but I also feel strongly that we 
need to have a good SREG 1.1 spec because in practice today there are 
lots of SREG implementations and it is important to be able to 
interoperate with them even if in the long term we'd like to move to AX.

This is, incidentally, why I was previously proposing forming an SREG 
group whose task is *only* to fix the spec to reflect current practice. 
This should encourage SREG interop in the short term while new 
developments to AX will encourage a move to AX in the longer term.

specs mailing list

Re: Request for consideration of AX 2.0 Working Group Charter Proposal

2009-01-25 Thread Martin Atkins

Henrik Biering wrote:

If the range of SReg attributes is expanded, however, I would suggest to 
add phone number (incl. quality as suggested for email) and possibly 
street+city address line(s). That would make it possible to fill in a 
somewhat larger part of typical registration forms.

It might be good to apply the quality thing to all of the fields.

One approach might be to add a verified argument that contains a list 
of names of fields that the OP has verified in some way.

However, I think the SREG spec itself needs work done since the 1.1 
draft (that was never published) has a bunch of problems. It might be 
better to do such work in a separate working group; I already have an 
updated 1.1 draft with some of the problems from the current 1.1 draft 
fixed that could potentially be used as a basis, though I'll need to dig 
it out since I'm not sure what I checked it in to.

specs mailing list

OpenID Authentication 2.0 Errata

2009-01-06 Thread Martin Atkins

Hi folks,

It seems that we don't currently have any central place to document the 
issues with OpenID Authentication 2.0, so I started a wiki page for it:

Currently it only has one issue, which is the one that I encountered 
today that inspired me to do this.

The proposal to create Auth 2.1 mentioned that there are other errata 
that should be included in that spec, so adding those here ought to be 

specs mailing list

Re: Request for consideration of Working Group Charter Proposal

2008-12-23 Thread Martin Atkins
Allen Tom wrote:
 Hi Nat - I'm not quite sure what you mean by class.

Nat previously talked about the idea of bundling several attributes 
together into a single namespace rather than assigning a URL to each 
individual scalar attributes. He referred to it as a class though you 
might instead want to think of it as a struct.

As I recall (I can't find the original message right now) the propsal 
went something like:


This way the URL is only included once, making the overall message shorter.

specs mailing list

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

2008-12-02 Thread Martin Atkins
Allen Tom wrote:
 For the time being, we prefer to require CKs for client applications 
 (even if they can't be verified) mostly to make it easy for us to pull 
 the plug on specific applications if they are discovered to be severely 
 buggy or dangerous. We'd also like to require pre-registration of CKs so 
 that we know who to contact about a particular app if we have any questions.

If I make a dangerous app using the consumer key from a popular 
application, would you black list that key and inconvenience all of its 

(I doubt it.)

specs mailing list

Completing the SREG 1.1 specification

2008-11-28 Thread Martin Atkins

Hi all,

It recently became apparent that version 1.1 of the Simple Registration 
Extension (SREG), which updates the protocol to work as an OpenID 
Authentication 2.0 extension, was never finished and published.

Furthermore, it has been noted that the latest draft contains 
ambiguities about how SREG is to be used in 1.1 vs. 2.0 messages, and 
that in some cases it does not describe how SREG is used by popular 
implementations today.

I'd like to form a working group to get version 1.1 completed, with a 
focus on simply writing down what current implementations do to aid 
interoperability rather than making any changes.

I have a draft of a more formal working group proposal prepared, but 
first I'd like to see who is interested in working on this. The minimum 
membership for an OpenID Foundation working group is five members. I 
anticipate that this group's work will be done relatively quickly, since 
we'd merely be documenting established practice.

Please reply here if you'd be interested in joining this working group, 
and in particular whether you are willing to be listed as a proposer in 
the working group proposal.

I have included below my current draft working group proposal. I welcome 
any comments on it.


OpenID Authentication 2.0 was finalized this past December and since
has started to see quite reasonable adoption. Many implementations
of Authentication 2.0 have made use of the Simple Registration
Extension that was popularized as an ad-hoc OpenID 1.1 extension.

While SREG is compatible with and has been deployed using the more
formal extension mechanism described in OpenID Authentication 2.0,
a 2.0-compatible version of SREG was never published. A draft
revised version is available [1], but it was never approved as
a specification and contains some ambiguities about how SREG
is used in 2.0 vs 1.1 messages.

This proposal is to form a working group to finish and publish
a version of SREG that is compatible with OpenID Authentication 2.0,
describing how SREG is used in existing popular implementations.

== Background information ==
Many implementors have extrapolated how SREG 1.0 can be used within
the extension mechanism defined in OpenID Authentication 2.0, but
this has actually never been documented in a specification. A draft
of SREG 1.1 was produced[1], but it was not published and has been
found to contain some ambiguities and deviations from established

== Working Group Name ==
OpenID Simple Registration Extension 1.1

== Purpose ==
To complete and publish the SREG 1.1 specification, documenting
how SREG is used by popular implementations today.

== Scope ==
The proposed work is as follows:
* Update the SREG specification to describe how it can be used as
an OpenID 2.0 extension as well as an OpenID 1.1 ad-hoc extension.
* Update the SREG specification to correct any deviations between
the specification and established implementation practice.

Note that this charter does not include adding new features to
Simple Registration; ideally, the specification produced by this
working group will merely be documenting existing implementation
practice, and will require no changes to existing implementations
as far as possible. Where implementations differ, an approach
will be chosen on the basis of number of deployments and on
consensus within the working group.

== Anticipated Contributions ==
* Feedback from library authors and other implementors about
how they have adapted SREG 1.0 to work within OpenID 2.0's
extension mechanism.
* Specification text to achieve the the goals described in
the above scope.

== Proposed List of Specifications ==
* OpenID Simple Registration Extension 1.1 (SREG 1.1)

== Anticipated audience or users of the work ==
Implementers of OpenID Providers and Relying Parties.

== Language in which the WG will conduct business ==

== Method of work ==
Work will take place primarily on the working group mailing list,
with the possibility of conference calls and face-to-face meetings
if deemed necessary by the working group.

== Basis for determining when the work of the WG is completed ==
Proposed changes will be evaluated on the basis of whether they
increase or decrease consensus within the working group.  The work
will be completed once it is apparent that maximal consensus on the
draft has been achieved, consistent with the purpose and scope.

* Martin Atkins, Six Apart ([EMAIL PROTECTED])
* David Recordon, Six Apart ([EMAIL PROTECTED])
* ...

Initial Editors:
* Martin Atkins, Six Apart ([EMAIL PROTECTED])
* David Recordon, Six Apart ([EMAIL PROTECTED])


specs mailing list

Re: Completing the SREG 1.1 specification

2008-11-28 Thread Martin Atkins

I agree that it's not ideal to have both, and in an ideal world everyone 
would use AX, but currently SREG seems to be more widely deployed than 
AX. This working group proposal was motivated not by some desire to 
needlessly perpetuate SREG but rather by actual real-world interop 
problems I've had to deal with as an implementer.

As long as folks still want to implement SREG, I think it's beneficial 
to have a specification that actually works in practice, which the 
current draft does not.

Dick Hardt wrote:
 A related topic.
 Wondering what the community thinks of having two specifications for 
 moving around profile data: we have SREG and AX: do we need both?
specs mailing list

Re: OpenID/OAuth hybrid - discovery

2008-11-24 Thread Martin Atkins
Dirk Balfanz wrote:
 I'm not sure I understand what the commotion is about :-)
 OAuth discovery (when it is done), will answer the question: given the 
 URL of a resource, where do I go to get access tokens for that resource. 
 The question answered by the XRD element described in Section 5 is does 
 this OpenID endpoint support the Hybrid protocol. These two questions 
 are somewhat related, but clearly different. And, yes, the latter is not 
 nearly as exciting as the former.

What is a consumer intended to do with this information?

Telling me that the OpenID provider also supports the OAuth hybrid 
protocol is not useful alone. It's not like I can just take any OAuth 
token in the world and feed it to this endpoint.

More useful, I think, would be to have the OAuth discovery information 
*at the service endpoint* say that the OAuth authorization URL for this 
service is some-url, and the combined OpenID/OAuth endpoint for this 
service is some-other-url. The first part of this will presumably be 
catered for by OAuth discovery. The second part seems like it ought to 
be an extension to OAuth discovery, though I don't have a good answer 
for what exactly it'd look like on the wire.

As currently speced, I'm not sure what problem that section is 
addressing or what value it provides. Perhaps for now it'd be better to 
take that part out of the Hybrid Protocol specification and defer that 
problem until it's clearer how OAuth discovery will work in general.

specs mailing list

Re: OpenID/OAuth hybrid - discovery

2008-11-24 Thread Martin Atkins
Dirk Balfanz wrote:
 We're defining an OpenID extension. Consumer will want to know whether 
 or not a given endpoint speaks that extension. That's all it's doing - 
 just like AX or PAPE have a section on discoverability. It also gives 
 consumers a way to look for the combined OpenID/OAuth endpoint (assuming 
 that one day we'll have these massive XRD documents advertising all 
 sorts of things - OAuth request token endpoints, portable contact 
 endpoints, etc.).

I guess I'm assuming that the OAuth service saying use that OpenID 
provider for hybrid OpenID/OAuth implies that the OpenID Provider 
supports the extension.

However, I guess the following flow could arise:
  * User does something that requires OAuth.
  * Consumer does OAuth Discovery (to be defined) and determines, 
amongst other things, the URL of the OpenID Provider that will do the 
combined OpenID/OAuth bit.
  * Consumer does discovery on the OpenID Provider and determines that 
it doesn't actually support the extension.
  * Consumer falls back on the non-combined flow, or just tells the user 
that the service provider is broken.

While it's nice to fail early in this case, the consumer still needs to 
deal with a bunch of post-authorization failure cases:
  * Provider claimed to support the extension but didn't actually return 
  * Provider claimed to support the extension but the approved request 
token doesn't actually work for some reason.
  * Provider claimed to support the extension but it turns out it 
doesn't support this particular sort of request token.
  * ...

In most cases, the implication from the OAuth discovery step will be 
enough and everything will work out. I'm not sure whether failing early 
in this one (unlikely) error case is worth the extra HTTP transaction(s) 
to find out whether the provider really supports the extension. It'd be 
more efficient to just send a request to the OpenID provider with the 
extension arguments and see if you get back a response.

specs mailing list

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

2008-11-18 Thread Martin Atkins
Allen Tom wrote:
 Manger, James H wrote:
 Ideally, an app would attempt to access a protected resource at an SP and 
 * A 401 Unauthenticated response from the SP; with
 * A “WWW-Authenticate: OAuth” header; with
 * A parameter providing the authorization URL; and
 * Another parameter with the OP URL (when OpenID/OAuth hybrid was supported).
 One  problem with this approach is that many SPs like Yahoo and MySpace 
 will require developers to register their site to get a Consumer Key. 
 Given that the developer already has to manually get a CK, there might 
 not that much value in defining a workflow for Consumers to discover the 
 OAuth endpoints.

As long as this is true it will be impossible for such SPs to expose 
non-proprietary protocols like PortableContacts, so either these SPs 
will need to find a way to work without pre-registration or we'll all 
have to accept that the open stack is impossible and go find something 
more productive to do.

specs mailing list

Re: Proposing an OpenID Authentication 2.1 Working Group

2008-11-11 Thread Martin Atkins

Here's the output from today's IIW session on this:

2.0 has been finalized
bunch of implementations
found lots of spec bugs

also gone and done oauth and email addresses and other things. Can we 
support these in the core spec?

- Making the spec more readable and fixing bugs (eratta)
   - Delegation
   - Error handling
- Adding a security appendix
   - could be a separate document referred to by the spec
   - possibly produced by separate group
   - Who controls this security page?
 - Security committee could look after this.
 - or Allen at Yahoo! will be editing a security document
- Clarifying XRI
   - Currently there's no firm message about whether RPs MUST support 
XRIs or not.
   - Need to clarify how exactly XRI should be used with OpenID.
   - Similar to the whitelist question.
- Clarify if RPs can white or blacklist what OPs they accept, and 
   - Discovery of type of identifiers an RP supports.
- Clarifying IRI
- Updating discovery. Possibly including the new-fangled XRD discovery.
- Clarifying whether association over SSL must/can use diffie-hellman.
- Discovery of support of checkid_immediate.

Exploratory work:
- Signature mechanisms. Looking at additionally supporting the 
mechanisms defined in OAuth so that they can be closer together.
   - Possibly deprecating the current signature mechanism.
   - Public keys?
- Email-shaped identifiers for OpenID
   - Could be a separate working group?

There was consensus that email-shaped identifiers would be worked on by 
a separate group and possibly rolled into 2.1 if it's done in time.

- Smart/rich clients?
   - Could be in this WG unless it ends up being a big change in which 
case it could be its own WG.
   - There's another session about this.

specs mailing list

Re: [OpenID] OpenID Extension to handle Emails Addresses?

2008-10-30 Thread Martin Atkins
David Fuelling wrote:
 I would even entertain the notion of the OpenID extension doing DNS 
 lookup first, then EAUT, though I need to think more on the topic.  
 Alternatively, maybe we make DNS optional.

At this point I'll throw in my more recent post about why DNS must be 
supported and must be the primary mode, with others as fallback:

However, I wouldn't necessarily object to putting the *EAUT* information 
  in the DNS rather than the OpenID information directly. The two things 
I care most about at this point are:

  * DNS must be consulted first, for the reasons I go into in that post.
  * In the case where an email address is the claimed_identifier, the 
OpenID request must have openid.identity set to mailto:theemailaddress, 
not the mapped HTTP identifer. (In other words, this is an extension to 
OpenID *Discovery*; the rest of the protocol is unchanged.)

The finer points of how we get there don't bother me that much. Being 
able to optionally redirect email addresses to URLs just as we can 
currently redirect URLs to other URLs would be good and consistent with 
the OpenID model that exists today. Preserving the ability to do 
delegation would be good so that I can use email addresses in my vanity 
domain without running my own OP.

specs mailing list

Re: [OpenID] OpenID Extension to handle Emails Addresses?

2008-10-30 Thread Martin Atkins
David Fuelling wrote:
1. The arguments about using DNS could apply to OpenID in general. 
   However, OpenID doesn't do anything with DNS.  Why is this?  What
   were the compelling reasons to not use DNS with OpenID?  Is there
   an FAQ page somewhere about that?  I have only vague recollections
   on the topic.

When you have an HTTP-based identifier, I think it makes sense to use 
HTTP to resolve it. So, just as with any other HTTP transaction, you:

  * As the DNS for the server that handles HTTP for the domain. (Which 
the A record in the domain has become the de-facto standard for, for 
better or worse. It'd be good if it were a SRV record, but whatever.)

  * You ask the HTTP server what's at the path given in the URL.

  * The response tells you the OpenID discovery information or, in the 
Yadis case, where to find the discovery information.

Now, you could argue (and people have argued) that using the MX record 
to find the mail server and somehow asking the mail server for the 
discovery information would be sensible. However, I would argue that 
this is overloading the concept of mail exchanger -- we don't use the 
MX record to discover IMAP or POP3 services either -- and that 
realistically speaking asking people to alter their SMTP server software 
is a complete non-starter.

You could also reasonably argue that my proposal of resolving 
[EMAIL PROTECTED] as is a layering 
violation, since the username part does not belong in the DNS. I 
wouldn't mind losing that if someone has an alternative proposal for 
making delegation work. (One such proposal would be to put EAUT endpoint 
information in the DNS, of course. I wouldn't object to that on principle.)

2. Do some of the larger email providers have an opinion on the
   mechanism used for Discovery in the email case?  For instance,
   would Google/Yahoo/etc prefer that DNS be consulted first, or that
   some HTTP-based discovery be consulted first?  Do they even care?

While obviously I can't speak for these big providers, my assumption in 
all this is that big providers can do whatever they like, whether it be 
altering the root of their website or putting stuff in DNS. Certainly 
the DNS change requirement hasn't stopped Hotmail or GMail supporting SPF.

I would of course be interested to hear from one of the big providers on 
this subject, since as far as I can tell they've been silent on it so far.

 However, I wouldn't necessarily object to putting the *EAUT*
 information  in the DNS rather than the OpenID information directly.
 The two things I care most about at this point are:
  * DNS must be consulted first, for the reasons I go into in that post.
  * In the case where an email address is the claimed_identifier, the
 OpenID request must have openid.identity set to
 mailto:theemailaddress mailto:theemailaddress, not the mapped HTTP
 identifer. (In other words, this is an extension to OpenID
 *Discovery*; the rest of the protocol is unchanged.)
 What if the user actually wants their URL to be the claimed identifier?  
 Would you be open to that?

I still haven't quite followed why, in that case, the user wouldn't just 
enter the URL into the OpenID box at the RP. If the user knows what a 
URL is enough to know they want to use it as an identifier, I think they 
can manage to type it in without relying on a layer of indirection to 
achieve that.

specs mailing list

Re: [OpenID] OpenID Extension to handle Emails Addresses?

2008-10-30 Thread Martin Atkins
Hallam-Baker, Phillip wrote:
 Well we already have a specification for that, it is the core 
 architecture of the Internet: DNS. We use the DNS SRV record for service 
 discovery. It is what it is designed for. It provides for fault 
 tolerance, load balancing, fall over just like an email MX record.

Thanks for another voice in favor of DNS. I was beginning to feel like 
the only one on this side of the fence. :)

 The simplest discovery mechanism then is:   SRV 1 100 80

I did consider SRV, but the return value from OpenID discovery is not 
a hostname, it's a structure like this:

  * Endpoint URL
  * Final claimed identifier (after following redirects)
  * OP-local identifier (or delegate in 1.1 terminology)
  * OpenID version (either 1.1 or 2.0, currently)

Some of these we can infer. For example, in my DNS-based proposal I just 
assumed that all email-based identifiers would use OpenID 2.0, because a 
provider's going to have to change their implementation anyway so they 
might as well upgrade to 2.0 while they're at it if they don't support 
it already.

I went with a TXT record with a custom serialization, despite it being 
technically incorrect, both so that the information required for the 
above structure could be represented and also so that it can be deployed 
on DNS providers that only allow A, CNAME, MX and TXT records to be 
configured. The latter is important for the delegation case, as the main 
  audience for delegation is people with vanity domains.

 OK so now lets think about market building a bit. Lets try to embrace 
 and extend the competition. In my view the value of OpenID is not so 
 much the protocol as the idea of an interoperable identifier. So lets 
 try to capture the SAML and WS-* worlds as well.
 We can do this with a policy declaration: TXT v=openid openid saml   SRV 1 100 80   SRV 1 100 80   SRV 1 100 80   SRV 1 100 80

And I infer from this that you're not adverse to the idea of encoding 
custom formats in TXT records, so hopefully you'll appreciate my approach.

However, if you've got an alternative proposal that's more DNS-pure 
I'd be happy to hear it. I don't claim to be a DNS expert. However, it'd 
take a very convincing argument for me to get behind anything that 
requires something other than A, CNAME, MX and TXT records though, for 
the reasons stated above.

(In case you haven't seen it, my current strawman proposal is here:

specs mailing list

Re: This is user's URI for Assertion Quality Extension

2008-09-05 Thread Martin Atkins
SitG Admin wrote:
 I'd like to see the 4th draft of this include a URI level 
 authentication property.
 I'd like to know whether the OP is asserting that the user is a member 
 of Site, is this specific user *at* Site, or is a member of Site and 
 we've generated this unique Directed Identity for them that won't reveal 
 their userID at Site but will allow you, the RP, to distinguish between 
 this anonymous Site user and other anonymous Site users.

What's the use-case?

specs mailing list

Re: Backporting the 2.0 extension mechanism to 1.1

2008-08-12 Thread Martin Atkins
Nat Sakimura wrote:
 Actially, that interpretation is not right. In draft 3, we have made it 

Draft 3 now seems to say:

 For the purposes of this document and when constructing OpenID 1.1
 and 2.0 messages, the extension namespace alias SHALL be pape.

Which now seems to require that pape must always be the namespace 
alias, in both 1.1 and 2.0. I don't understand what the intention of 
this sentence is if this is not a correct interpretation.

However, my original message was not really a comment on the PAPE spec 
so much as a comment on the general lack of an extensibility mechanism 
in OpenID 1.1. The PAPE spec (the sentence I quoted above 
notwithstanding) currently seems to assume that the 2.0 namespace 
mechanism is available in 1.1, but as far as I'm aware there has never 
been a published specification allowing this. (please correct me if I'm 

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.

specs mailing list

Re: OpenID 2.0 Specifications

2008-08-11 Thread Martin Atkins
Arshad Khan wrote:
 Can I please have OpenID 2.0 specifications?
 Can I also request link to software codes for sever and consumer?

specs mailing list

Re: OpenID 2.0 Specifications

2008-08-11 Thread Martin Atkins
Arshad Khan wrote:
 Hi Martin,
 Thanks for this.
 Is it possible to get the specification in word or pdf format?

I don't think this is published online, but you should be able to load 
the HTML version into Word and save it as .doc if necessary.

 Also, I am not clear if I need to read and incorporate the following 
 specifications in addition to OpenID 2.0 Authentication document
 - OpenID Attribute Exchange 1.0 – Final
 - OpenID Simple Registration Extension 1.0

These are optional extensions to OpenID and so you only need to read 
them if they are important for your application.

  - OpenID Authentication 1.1

This is the older version of OpenID Authentication; a compatibility 
mode for this is documented in the 2.0 spec and supported in the 2.0 

 Sorry, I am new to this.
 Also, can you please advise if PHP version of code is available? has a PHP library as well as Python and Ruby 

specs mailing list

Backporting the 2.0 extension mechanism to 1.1

2008-08-11 Thread Martin Atkins

I notice that, like sreg, the pape extension is supporting 1.1 by simply 
hard-coding the pape prefix on its arguments.

This approach is troublesome for the Net::OpenID::Consumer perl library 
because it deals only in extension URIs, and supports sreg in 1.1 as a 
special case. In order to preserve the abstraction the library would 
need to be altered each time an extension adds a new hard-coded prefix 
in this way, which is not ideal.

Therefore I'd like to propose that for PAPE and all future 
specifications the 2.0 extension mechanism simply be allowed in 1.1. I 
don't think it needs any modification in order to work for 1.1, except 
that for legacy reasons SREG should continue to have the sreg prefix 
reserved when in 1.1 mode.

specs mailing list

Re: Backporting the 2.0 extension mechanism to 1.1

2008-08-11 Thread Martin Atkins
Johnny Bufu wrote:
 On 11/08/08 12:49 AM, Martin Atkins wrote:
 I notice that, like sreg, the pape extension is supporting 1.1 by 
 simply hard-coding the pape prefix on its arguments.
 Where/how? To my knowledge the opposite is true, per the last paragraph 

In that referenced section it says:

 For the purposes of this document *and when constructing OpenID 1.1
 messages*, the extension namespace alias SHALL be pape.

(emphasis mine)

I understand that to mean that when making a 1.1 request the alias must 
be pape.

specs mailing list

Re: Responding to a 2.0 request with a 1.1 response

2008-07-20 Thread Martin Atkins
(sorry for responding to myself.)

Martin Atkins wrote:
 Another similar and perhaps more likely case is when a user does 
 2.0-style delegation to a identifier, omitting the 1.1-style 
 delegation. Net::OpenID::Consumer with 1.1 compatibility enabled fails 
 in this case because the 1.1 version of the OP does not appear in the 
 list of discovered providers.

In fact, having read my logs in a little more detail, I see that this 
mid-flow switch actually breaks delegation altogether in Net::OpenID, 
because in the 1.1 case we put the user's identifier in an 
oic.identity argument inside the return URL, but in the 2.0 case we 
use the standard openid.claimed_id argument instead.

For, we send out the 2.0 request with openid.claimed_id, but 
when they send back their 1.1 response openid.claimed_id is not 
available and their server doesn't know (and shouldn't know) about our 
non-standard oic.identity argument.

Having noticed this I'm pretty convinced that switching versions 
mid-exchange is harmful and should be explicitly forbidden by the 
specification; I don't think there's really any way that a mid-exchange 
switch could be specified that didn't suffer from this flaw.

specs mailing list

Re: Using email address as OpenID identifier

2008-04-07 Thread Martin Atkins
Paul E. Jones wrote:
 Perhaps it is important to say, though, that I do not think it requires 
 the e-mail providers to get on board with this (in my view) simpler 
 notation.  I could use an ID like [EMAIL PROTECTED] and that should 
 work, if would publish the appropriate NAPTR record.  I 
 could also insert NAPTR records into the DNS server that 
 would allow me to use my email address, but point at my preferred OpenID 
 provider.  In short, just because the [EMAIL PROTECTED] syntax is used does 
 not mean that it necessarily an e-mail address: it could be, but more 
 importantly, it just follows that familiar format documented in RFC 822.

Funnily enough, I've always percieved the fact that syntactically-valid 
but non-existant email addresses are being used as identifiers as a 
problem rather than a benefit:

  * It creates confusion for users when something looks like an email 
address but it doesn't behave as one. I've seen this sort of confusion 
with Jabber servers, where users get confused that their Jabber ID and 
email address are not the same, especially when Jabber clients say For 
example, [EMAIL PROTECTED] under the Jabber ID field.

  * If not all email-shaped OpenID identifiers are actually working 
mailboxes, it's likely to lead to a distressing user experience where 
the user is first asked to enter their OpenID identifier -- that is, 
their email address -- and then they're asked to enter and verify their 
email address. At this point, I expect users to at best say Stupid 
computer! Remember what I've told you! and at worst get confused and 
think that the OpenID identifier they entered was not correct.

  * As has often been raised in both the OpenID-with-email and in the 
Jabber circles, many people are reluctant to give up their email 
addresses to the public eye for fear of spam. Note that will, 
by default, use a big opaque string as an identifier rather than the 
user's Yahoo! account name for this very reason.

specs mailing list

Re: Using email address as OpenID identifier

2008-04-07 Thread Martin Atkins
Paul E. Jones wrote:
 I’ll give you that one: that’s certainly easier.  But, does not cause 
 some confusion?  After all, one’s identity is not, but that is 
 the identity provider.  Perhaps the prompts around the Internet ought to 
 Say “OpenID Provider:” instead? :-)

I propose that the caption be Whatever your OpenID provider told you to 
enter: .

(I joke, of course. Mostly.)

specs mailing list

Re: handling of url redirection

2008-02-28 Thread Martin Atkins
Jonathan Daugherty wrote:
  This is what I was getting at- it'd be good to give users an identical
  experience when they sign into various OpenID-enabled apps.
 Just to be clear, this is not an interop issue.  This is a matter of
 drawing the line between what is sane and what is not.  For
 pathological cases (e.g., excessive redirects) there isn't a sane
 interop behavior, only a sane fallback behavior.  +1 for
 _recommending_ a maximum number of redirects in the spec so
 implementors have some idea of what is sane.  I think any more than 10
 is pathological.

It may be worth noting that some implementations have both a limit on 
the actual number of redirects and on the total time for the request, 
including all redirects. In otherwords, unreasonable redirects can be 
measured by the time taken to do them rather than their actual number.

specs mailing list

Re: Integration with Enterprise Directory Services

2008-02-28 Thread Martin Atkins
Drummond Reed wrote:
 Yes, Marty Schleiff at Boeing is working on an RFC for how to represent XRIs
 in an LDAP directory for that very reason -- to establish standard OIDs for
 this attribute. LDAP already has a URI attribute type, but downcasting an
 XRI into a URI just to squeeze it into that attribute type loses the
 semantics that the XRI is an abstract identifier for the resource. So Boeing
 wants to establish OIDs for primary-xri (value of the canonical XRI) and
 alt-xri (value of any other XRI synonym).

This is perhaps a bit of a tangent, but what are the disadvantages to 
representing XRI as a URI? It seems to me that having two completely 
orthogonal sorts of identifier rather than having one be a subset of 
the other just makes things needlessly complex. What makes you consider 
XRI to be an abstract identifier but a URI not to be?

The whole thing of just starting with an equals sign is very cute, but 
surely that's just a shorthand to avoid writing xri:// in contexts 
where it's unambiguous, much like people routinely write things like when an http: URI is expected.

specs mailing list

Re: SREG 1.1 Request parameters

2008-02-22 Thread Martin Atkins
Enis Soztutar wrote:
 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.

This distinction is made to avoid the following flow, which isn't very 

  1. RP sends user to OP with a request for email address.
  2. OP asks user whether or not to send email address.
  3. User elects not to send email address.
  4. RP then says We can't let you register without an email address. 
Type one in here.
  5. User elects to supply an email address after all, but now has no 
assistance from the OP to complete this field.

By having the optional/required distinction, in step two the OP can say 
something like The RP may not allow you to log in without this 
information. This means that the user can make the decision in step 3 
with the knowledge that it probably won't succeed, or he can make the 
decision in step 5 a few steps earlier and get assistance from the OP to 
enter the email address.

It's only a very subtle distinction, but it is important so that the OP 
can explain the situation to the user at the right point in the transaction.

specs mailing list

Re: OpenID Inline Authentication Extension 1.0 Draft 1

2007-09-03 Thread Martin Atkins
John Ehn wrote:

 Thanks for the response!  I'm looking at those specs now, and I really 
 like the flow of the HTTP Authentication spec, because it looks like 
 it's solving the problem of passing the OpenID Identifier to the RP in 
 an automated way, which is really cool.  Looks like it needs to be 
 fleshed out in some parts, though.

Both of these specs need work. What you see up there on the wiki is 
really just a brain dump wanting to be turned into a spec. I've not 
really had much time to work on them, though.

 As for the Signature Request protocol, I'm not quite sure what it does 
 yet, but I'll let you know my opinion once I've digested it.

The HTTP Authentication spec has a part in it where it says the client 
must get a signature from somewhere. When I originally specced it my 
only answer here was that non-human agents can act as their own OP and 
therefore they could just compute the signature themselves, but 
realising that this protocol had applications for humans authenticating 
to services inside specialised rich clients ('s Audioscrobbler 
API, for example, or JOSM for OpenStreetMap) I added Signature Request 
Protocol as a standard mechanism for rich client RPs to obtain a 
signature from the user's OP.

As I think it notes somewhere in the copy, I'm imagining in the ideal 
case a desktop service or at least a shared library that does the SRP 
bit on behalf of all of the user's applications, so that each 
application does not need to be given the user's OP credentials. It was 
my hope that it could theoretically be integrated with systems like 
Apple's Keychain.

However, SRP is still very rough-and-ready and still has lots of 
outstanding issues. I think Inline Authentication might have the answer 
to some of these issues.


specs mailing list

Re: Do We Agree on the Problem We're Trying to Solve?

2007-06-12 Thread Martin Atkins
Josh Hoyt wrote:
 On 6/11/07, Martin Atkins [EMAIL PROTECTED] wrote:
 Presumably the recommendation would be to have several identifiers
 attached to a single account just as is recommended today. I would point
 most of my identifiers at one canonical identifier but retain one or
 more special backup identifiers that do not point at my persistent
 identifier so that I can reclaim my account if my persistent identifier
 goes away.
 Why bother with a canonical identifier if you're going to need
 multiple identifiers attached to an account anyway?

Why bother using OpenID if you need to have multiple identifiers 
attached to your account anyway?

specs mailing list

Re: The CanonicalID Approach

2007-06-11 Thread Martin Atkins
Josh Hoyt wrote:
 On 6/9/07, Martin Atkins [EMAIL PROTECTED] wrote:
 I'm assuming that the RP authenticates, not Just as with delegation, if I can
 successfully authenticate as the persistent identifier and the
 non-persistent identifier points at the persistent one, we can assume
 that is me as well.
 If you agree that:
 1. In order to authenticate as the persistent identifier, discovery
 must be done on the persistent identifier
 2. In order to determine that the non-persistent identifier points at
 the persistent one, discovery must be done on the non-persistent

Right you are. The detail I was missing was that if, as in delegation, 
the non-persistent identifier is trusted to nominate a server endpoint 
for authentication, it becomes possible to lie about the server endpoint 
and claim any identifier.

But can we guarantee that it is always exactly two discovery steps? If 
my CanonicalID points at an identifier which itself also has a 
CanonocalID, do we follow it recursively?

I can't really think of any security flaws as a result of only following 
one level of CanonicalID, but it may be counter-intuitive for implementors.

specs mailing list

Re: The CanonicalID Approach

2007-06-09 Thread Martin Atkins
Josh Hoyt wrote:
 On 6/8/07, Martin Atkins [EMAIL PROTECTED] wrote:
 I figure that you could potentially use the same mechanism as delegation
 to avoid the extra discovery iteration.

 The problem, as with delegation, is that you need to duplicate the
 endpoint URL in the source identifier's XRDS document. The canonical
 identifier must also support OpenID, which I believe is something they
 were trying to avoid.
 I'm assuming that by saying it's like delegation, you mean that the
 canonical identifier is discovered from the entered identifier, and
 sent to the server, but discovery is never done.
 Let's say that you use; as your identifier,
 with a canonical id of;
 I can set up a URL; that points
 to an OpenID provider that I control, and give it the same canonical
 Unless we make sure that the canonical ID is intended to be used with
 this OpenID server, I can sign in to your account anywhere, since the
 canonical ID is used as the database key.
 Were you thinking of a different mechanism?

I'm assuming that the RP authenticates, not Just as with delegation, if I can 
successfully authenticate as the persistent identifier and the 
non-persistent identifier points at the persistent one, we can assume 
that is me as well.

specs mailing list

Re: The CanonicalID Approach

2007-06-08 Thread Martin Atkins
Josh Hoyt wrote:
 On 6/7/07, Recordon, David [EMAIL PROTECTED] wrote:
 What I'd like to markup is that my three reassignable identifiers so
 that they all use my LiveJournal userid URL as the persistent
 identifier.  It should be noted that also marking them as synonyms to
 each other follows the same sort of process using the Ref/ tag in my
 various XRDS files.
 -1 on requiring a whole extra round of discovery for every sign in. If
 you can come up with a way to verify that (a) the identifier in
 question points to the canonical ID and (b) the canonical ID has the
 appropriate information in it without doing twice the discovery, I'd
 like to hear it.

I figure that you could potentially use the same mechanism as delegation 
to avoid the extra discovery iteration.

The problem, as with delegation, is that you need to duplicate the 
endpoint URL in the source identifier's XRDS document. The canonical 
identifier must also support OpenID, which I believe is something they 
were trying to avoid.

specs mailing list

Re: Generalized solution to OpenID recycling (was RE: The WordPress User Problem)

2007-06-05 Thread Martin Atkins
=drummond.reed wrote:
 As Martin has pointed out, the purpose of the CanonicalID element in XRDS is
 to support reassignable-to-persistent identifier mapping. Although this is a
 native function of XRI resolution (because XRI architecture was explicitly
 designed to address the reassignable-to-persistent synonym mapping problem
 and thus has explicit syntax for reassignable and persistent identifiers),
 there is nothing to prevent CanonicalID mapping from being done with URLs.
 Discussion on this thread so far has only entertained using this mechanism
 to handle reassignable-URL to persistent-XRI mapping, however there's
 nothing to prevent it being used for reassignable-URL to persistent-URL
 mapping, or even reassignable-URL to persistent-URN mapping (as long as the
 URN is resolveable, such as a Handle ID).
 Everything is already in place in XRDS architecture except the Canonical ID
 verification rules. The OASIS XRI TC has already published the
 reassignable-XRI-to-persistent-XRI Canonical ID verification rules in the
 first editor's draft of XRI Resolution 2.0 Working Draft 11 (a more detailed
 explanation of those rules will be in the second editor's draft due out
 tomorrow). Per Martin's suggestion, in the second editor's draft will also
 add the Canonical ID verification rules for
 reassignable-URL-to-persistent-XRI mapping.
 I see no reason we can't add the rules for
 reassignable-URL-to-persistent-URL mapping as well, since it's simply a
 matter of the RP confirming that the persistent identifier is also
 authoritative for the XRDS.

I think that URL-to-URL is more useful in the short term, because 
(unless something's changed since we last talked) you can't currently 
get an i-number without purchasing an i-name.

This does, however, raise a transitional issue: as soon as providers 
start publishing CanonicalID, all of the existing accounts are 
effectively broken because the primary key is being changed.[1]

If LiveJournal were to suddenly start publishing in the XRDS for that the CanonicalID were (for example) frank would lose his 
account on any site he had already been using.

For this to work out, RPs would have to change to retaining a list of 
synonyms rather than simply keying off the CanonicalID, but then that 
defeats the object of creating the ability for identifiers to be recycled.

The only solution which springs immediately to mind is to get all of the 
big OP players to implement this and then have the burden be on RPs to 
handle the migration from the old display identifiers to the new 
CanonicalIDs as they transition from 1.1 to 2.0. This only works if 
things are changed in a particular order, though.

I'm attracted to the cleanliness of using the same CanonicalID mechanism 
for both URLs and XRIs and any combination of the pair, but unless the 
above can be resolved I don't think it's workable.

[1] This issue exists for the fragment approach too, but with the 
obvious solution that you simply don't starting appending a fragment 
until an identifier enters its second generation. This solution is not 
appropriate for CanonicalID because it has more broad semantics than 
simply identifying the generation number of the identifier.

specs mailing list

Re: Auth 2.0 Extensions: Namespace Prefixes

2007-06-05 Thread Martin Atkins
Johnny Bufu wrote:
 On 5-Jun-07, at 8:53 AM, Granqvist, Hans wrote:
 But it seems superflous: Since you cannot depend on args to
 be ordered[1], you'll still need to iterate and match prefix
 to values.
 Martin's proposal seems like a minor improvement to me - iterating  
 thorough openid.ns.* or splitting the value of openid.extensions and  
 then iterating through the result seems roughly equivalent.
 Our implementation builds a map of extension aliases to namespaces  
 when a message is received and after that, at any point during the  
 life cycle of that message, extensions queries are  simple and quick  
 map lookups.
 So I'd rather not add the openid.extension field.

For what it's worth, I'm no longer in favour of my own proposal. :)

It was ill-thought-out and does not solve the problem I set out to solve.

My intention was to create a situation where the question of Is 
extension x used in this request requires a single dictionary lookup, 
which the extensions field does not solve.

Since that is not really workable without moving away from the use of 
URIs to identify extensions, I'm happy to accept this small wart for the 
sake of keeping things sane and simple.

specs mailing list

Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification

2007-06-03 Thread Martin Atkins
Claus Färber wrote:
 Marius Scurtescu schrieb:
 The new attribute values are needed in order to signal an OpenID 2  
 Why is this necessary? Is OpenID 2 incompatible? In other words, what 
 happens if an OpenID 2 Relying Party tries to talk to an OpenID 1.x 
 If the OpenID 1.x Provider just ignores additional message fields (i.e. 
 treats them like an unknown extension), then no new rel values are 
 needed. If this is not the case, maybe the OID 2 spec can be changed to 
 make it possible.

One incompatibility that springs to mind is that it is permissable to 
talk to a 2.0 OP via a POST request with the arguments in the entity 
body, while a 1.1 will likely barf on this since 1.1 only allowed for 
GET requests with the arguments in the query string.

A 2.0 RP that uses a GET request and uses extension prefixes that match 
the ad-hoc field names used for the 1.1 extensions could, in theory, 
talk to a 1.1 OP without any problems. That is, unless I've missed 
something. :)

specs mailing list

Re: Specifying identifier recycling

2007-06-01 Thread Martin Atkins
Johnny Bufu wrote:
 We did look at this (with Drummond) in December. The bottom line is  
 that it can't be done easily - a mechanism similar to XRI's canonical  
 ID verification would have to be employed, to confirm that the i- 
 number actually 'belongs' to the URL on which discovery was  
 initiated. (Otherwise anyone could put any i-number in their URL- 
 based XRDS files.)

Indeed, CanonicalID verification would be necessary, but it's already 
necessary if you want to accept XRI-based logins anyway.

Last time we were talking about this CanonicalID verification for XRI 
was not yet specified. Is it now specified somewhere?

specs mailing list

Re: Specifying identifier recycling

2007-05-30 Thread Martin Atkins
John Panzer wrote:
 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.

If you're going to use i-numbers, then there's no reason at all not to 
use the XRD CanonicalID element. The same mechanism that's used to map 
i-names onto i-numbers can also be used to map URLs onto i-numbers, or 
URLs onto other URLs.

I'm sure Drummond can talk in more detail about this. We did discuss it 
briefly at IIW, but once the majority had decided that the fragment 
approach was the way to go we didn't get a chance to investigate this 

specs mailing list

Auth 2.0 Extensions: Namespace Prefixes

2007-04-30 Thread Martin Atkins

As currently defined, an extension has a global namespace URI as well as 
a request-local alias/prefix. For an extension with the namespace that has a field foo, the following fields are 
to be sent:


It seems to me that the only way to discover the extension namespaces 
used in a particular message is to iterate over all keys looking for 
openid.ns.(\w+) and then see if the value matches.

This seems ugly since usually webapps deal with such arguments as a 
dictionary structure, and use dictionary dicipline while interrogating 
the values.

If we added an extra field:

then the extensions used in a message would be accessible by splitting 
that field on its commas and then accessing openid.ns.whatever for each one.

It's still not ideal, of course; it'd be better if the full namespace 
URI were included in the key part of a (key,value) pair, but many 
frameworks[1] can't deal with wacky punctuation characters in the key.

[1] I'm looking at you, PHP.

specs mailing list

Re: Authentication Protocols for Non-browser Apps

2007-04-10 Thread Martin Atkins
Gabe Wachob wrote:
 Hi Mart-
   I'm trying to figure out if what you are proposing covers the same
 use case that I discussed at
   I'm not clear actually what you are trying to do with HTTP
 Authentication, and it may be completely unrelated to my use case, or it
 could be squarely in the same place. 
   In your proposal, is there any interaction with a user? If so, when?
 All I see is that the caller sends a signature with the authenticated
 request. Is this implying that the caller performs some function with the
 OP to generate this signature? How does this happen? Can I use an existing
 OP with my URL or XRI to generate this signature? If so, how? 

The HTTP authentication bit does not specify how the signature is 
obtained. This is because when some application service is 
authenticating as itself it can maintain its own associations and 
generate its own signature without the indirection.

Where the Signature Request Protocol comes in is making this protocol 
applicable to user authentication as well. Unfortunately, it *does* 
require the OP to support an additional protocol mode where the user is 
authenticated using HTTP authentication (or some other 
machine-interpretable authentication) rather than HTML forms and 

The flow I'm expecting for the latter is, to take the client[1] 
as an example, that the user will enter an identifier URI into the 
preferences dialog where currently a username/password is entered. When 
the client-side app needs to make a request, it'll first do an 
unauthenticated request and see what HTTP authentication mechanisms are 
supported, and then prompt the user for appropriate credentials.

In the future, I'm hoping that the signature-fetching steps will be 
replaced with call into an installed system service which will prompt 
the user to release a signature, thus avoiding the need for the user to 
give up the credentials to the client app and allowing the user to 
approve each application is is often done with a desktop firewall.

specs mailing list

Re: password-free login without SSL and OP reliance (an anti-phishing solution)

2007-04-07 Thread Martin Atkins
Douglas Otis wrote:
 For clarity, OpenID Authentication 2.0 - Draft 11 4.1.1. Key-Value  
 Form Encoding should change to something like Keyword-Value Form  
 Encoding.  Avoid using the word key to mean field or label.  This  
 will cause confusion.

While I believe that key-value pairs is a common enough term that 
confusion is unlikely by any knowledgeable developer, I suggest that if 
it be changed it be changed to name-value form encoding, since I think 
this is more commonly used than keyword-value.

specs mailing list

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

2007-04-07 Thread Martin Atkins
Johnny Bufu wrote:
 I believe a key difference here is between what people would be  
 willing to do, and what people actually (will) do. For example:
 - I would be willing to go to a rugby game, but I don't know if any  
 of my friends are going, so I probably won't go
 - most of my friends who like rugby may be thinking and acting the  
 same way, or
 - most of my friends would go if they knew rugby, but they haven't  
 discovered it yet.

 From a purely selfish point of view, I'm happy for this discussion to 
take part on the specs list just so I don't have to join and configure 


specs mailing list

Re: Moving AX Forward (WAS RE: SREG namespace URI rollback)

2007-04-07 Thread Martin Atkins
Johnny Bufu wrote:
 These two seem to have been the rationale of the recent discussions  
 about splitting the OpenID spec into core/discovery/etc., which  
 seemed to make sense to a number of people (I'm just not sure if it's  
 worth / good tactical move at this stage).

I tend to think it's a good idea to modularize specifications in the 
same way as you'd probably modularize the implementation. This is why[1] 
I was pushing for separate Auth / service discovery stuff: the service 
discovery stuff is obviously useful for things other than auth, and 
there are *already* separate libraries for it (Service::Yadis and 
friends), so it makes sense for it to be given as a separate specification.

On the other hand, I also think it's a good idea not to modularize too 
early: until there's some implementation experience, it's hard to say 
with certainty what parts make sense as distinct modules. I'm not that 
familiar with the AX stuff yet, but my gut feeling is that it'd be a 
good idea for someone to make an experimental implementation to get some 
implementation experience and then it'll probably be a lot more clear 
where the articulation points are that make spec modularization 
worthwhile. There's little point in debating it at this early stage, in 
my opinion.


[1] One of the reasons, anyway. The other reason was to reach a 
situation where the OpenID Authentication specification can largely 
reference only other specifications under the OpenID umberella, which 
means bringing the Yadis tech into OpenID land (which it basically 
already is, despite the distinct brand) and defining a subset of the 
XRDS schema to avoid referencing the entirety of XRI Resolution 2.0, 
which contains lots of stuff that is not necessary for OpenID and 
related tech.

specs mailing list

Re: Server-to-server channel

2007-04-05 Thread Martin Atkins
[I initially sent this to Chris directly, because he sent his message to 
me directly. Then I noticed he'd also replied on the list. Hopefully 
he'll see this before my private reply and we can avoid another 
go-around of duplicate messages!]

Chris Drake wrote:
  MA For some things it's legitimate: they need to store your name because
  MA otherwise they'd need to talk to your OP (via you!) every time they
  MA render a page containing something attributed to you.
  OK - yes - I concede that some data age complexity does probably
  creep back in if RPs choose to deny users the opportunity to audit the
  use of user information.  (If I've got a choice between 2 RPs, and RP1
  renders pages with my name in it, without giving me control over that,
  while RP2 makes repeated calls to my OP every time it occurs: I'll
  always choose to use RP2 - because it's the only one of the 2 options
  that's user centric, and gives me the ability to control the use of
  my information.
  Yes - this could be a tough drain on RP and OP resources.  Tough.

You can't just wash your hands of this problem because it doesn't suit 
your rather bizarre idea about how the world should be. Sites need to be 
able to attribute contributions to users, and in order to do that they 
need the user's name. A forum site cannot retrieve the name of every 
user that took part in a topic from their respective OPs while rendering 
  the topic page. Tough is not an acceptable answer: rendering a topic 
page is a legitimate function of a forum site and attributing each 
message is necessary.

  MA they need to store your name because
  MA otherwise they'd need to talk to your OP (via you!)
  via you! is not a correct statement.  This is a server-to-server
  topic: we're discussing a data flow that is by your explicit prior
  permission, but that takes place when you are not necessarily

Right. Some people had been talking about not allowing this out-of-band 
information fetching. Even without the need for the user to be present, 
it's still prohibitively expensive.

  MA For other things it's more dubious than that, but the fact that it
  MA is technically possible means that at least some RP's will do it.
  MA I think it'd be a mistake to write the spec under the assumption
  MA that they won't unless we're going to include something that
  MA prevents it.
  I do not follow your logic.  It looks like you're saying there is an
  opportunity for some RP's to act badly, therefore we should not even
  try to code user-protection into the protocol

On the contrary, I'm saying that if you don't want RPs to retain user 
information then you should include some TECHNICAL MEASURE that prevents 
them from doing so.

I think an acceptable compromise is to instead give users a way to 
express their wishes about how the data can be retained in the form of a 
update this every n months/weeks/years/whatever or a hard expires on 
this date-type rule. This way you acknowledge that there are indeed 
applications that need to retain user information for certain purposes 
and allow the user to have some control over this process. You could 
also put in a don't retain this at all flag, which in my forum case 
would probably cause the forum to just identify you by your raw OpenID 
identifier and have done with it.

  By all means - include preventative code (and for some kinds of
  attributes, digital time-stamped and signed assersions about the
  attributes solve these problems).  But I think it's a far bigger
  mistake to completely leave out a server-to-server channel altogether.

I have nothing against the server-to-server channel. In fact, the 
server-to-server channel is a prerequisite for the update this every n 
months thing because otherwise the RP would have no way to do that update.

  When a rogue RP violates your trust and caches data without your
  permission, that's bad.

So a way is is needed for:

  * A trustworthy RP to indicate how long it would like to retain 
certain items of data
  * A user to indicate how long he would like certain items of data 
retained for, or how often the RP should try to refresh that data.
  * A way for the user to prevent further updates of a particular 
attribute by a particular RP after a certain date.

The first and second points above would, I think, be helped by defining 
some reasonable defaults for each attribute type, just so that the 
average user doesn't necessarily have to spend ages entering update 
frequencies and expiry dates every time some attributes are requested 
for the first time.

specs mailing list

Re: Server-to-server channel

2007-04-05 Thread Martin Atkins
Chris Drake wrote:
 Hi Martin,
 Yes - sorry - I accidentally hit reply instead of reply all. I
 later did re-post to the list though.  For the benefit of the list,
 your reply is at the end here.
 Re-reading my reply, I think my wording sounded pretty strong, and I
 might not have made it clear that I'm not pushing for 100% of data to
 live at the OP: rather - I want to give the user a choice in the
 matter (that is - after all - the entire spirit of user-centric). I
 want users to have the *option* to decide whether to sign up to RP#A
 or RP#B, and be able to base their decision upon the data-handling and
 protection practices of the RP.  Some RP's will want to store
 everything just like they do today.  Some will want to embrace user
 centricity and give their customers full control, and most will
 probably tread a line somewhere inbetween.
 As long as we build something that supports all this, then we can
 leave it up to the normal market forces to steer the Identity future
 the way they want - with the key issue (for us) being that OpenID has
 the chance to persist in this future.  Right now - OpenID is right at
 the bottom of the pile, being almost the worst Identity 2.0 protocol
 currently on the market.  IMHO - this is a problem that's easily

I believe we are aiming for much the same thing, though perhaps I'm 
coming at it from a different perspective. My original message was 
proposing support for expressing the user's desires for how long 
particular data items should be retained without refreshing them, which 
seems to fit into your world view as described above.

I was simply suggesting that expecting RPs to retain *no information at 
all* is unrealistic, and so we should provide a mechanism for users to 
express how they would like their data to be used rather than just 
assuming that RPs will retain nothing.

 I wrote:
 Yes - this could be a tough drain on RP and OP resources.  Tough.
 You wrote:
 MA You can't just wash your hands of this problem because it doesn't suit
 MA your rather bizarre idea about how the world should be. Sites need to be
 I contest that I *am* allowed to wash my hands at this point,
 because it is absolutely my problem: I operate an OP, and I'm involved
 in helping RPs accomplish Web 2.0 goals.  I'm smack in the middle of
 all the consequences that flow from allowing users to control their
 own data howsoever they wish. 
 I further contest that the idea of me being in control of my own
 information about me is not bizarre.  It might not be how anything on
 the web works today - true - but I'm pretty confident this is
 something most people do, or will, want.
 Imagine you're at the newsagent buying a magazine.  You hand over
 your credit card, and the shopkeeper says No problem - I'm happy to
 sell you your goods, but I need you to first agree to let me make a
 photocopy of your credit card, grab you name and email address, and 
 keep it in all on our files for the next 10 years.  Oh - and we'll
 need to be sending you the occasional marketing message from time to
 time over those 10 years as well.
 Now *that* is something that almost everyone will agree is bizarre.

Note that I was focusing on the example you gave of a user's name, 
rather than of a user's credit card information. Different data deserves 
different treatment. I'll wholeheartedly agree that it's undesirable for 
a vendor to retain credit card information — they currently do so 
largely because there's nowhere else that it can be centrally stored and 
retrieved, but AX changes that — but other data such as a user's name 
are another matter.

When I meet people, I routinely tell them my name. I don't expect them 
to immediately forget my name after our conversation — in fact, like 
most people, I'm probably subconsciously offended when people *don't* 
remember my name. I control people's access to that data by simply not 
telling them in the first place.

I think that what we can take from this misunderstanding is that not 
only do different *attributes* have different usage expectations, but 
also different *situations* have different usage expectations: you're 
largely focusing on businesses and financial transactions, while I'm 
largely focusing on social situations such as forums, weblogs and social 
networking. This may be caused by a difference in our backgrounds or 
interests, but whatever the reason it does show that different 
situations call for different behavior, and is yet another reason why 
users should be able to express their desires on a case-by-case basis if 
it is important for them to do so. I like Vinay's subsequent suggestion 
that this somehow be made legally binding, although I'm not sufficiently 
knowledgable about the relevant law to know how that can be put into 

specs mailing list

Re: Promoting OpenID

2007-04-04 Thread Martin Atkins
McGovern, James F (HTSC, IT) wrote:
 Is anyone here working with vendors in the ERP, CRM, ECM, BPM or VRM spaces 
 such that user-centric identity is built into their product?

Mm tasty acronym soup!

specs mailing list

Re: SREG namespace URI rollback

2007-04-04 Thread Martin Atkins
Recordon, David wrote:
 I see there being a gap between SREG and AX with nothing bridging it.
 IMHO, AX takes too large of a step for people to use it if they just
 want a few more SREG fields.  I think we need something which does
 nothing more than provide a way to extend SREG and that will solve the
 majority of problems today.

Presumably once we're on OpenID 2, those that need extensions can just 
define their own extension namespace. They can follow the conventions of 
SREG if they want, though of course they can really do whatever they 
like as long as it can be represented in an OpenID 2 request.

specs mailing list

Re: Server-to-server channel

2007-04-04 Thread Martin Atkins
Chris Drake wrote:
 Hi Martin,
 You wrote
 MA The age of the information needs to be taken into account here.
 When the information (rightly) lives at the OP instead of the RP, none
 of that age complexity exists.
 It's *my* name. It's *my* credit card. If any RP wants this info, make
 them come to me (my OP) and get it. Let me say no. Let me know each
 time they ask. But most importantly, let me (my OP) provide the
 correct, updated info each time the RP wants it.

I think you're kidding yourself if you believe that RP's won't cache the 
information they obtain.

For some things it's legitimate: they need to store your name because 
otherwise they'd need to talk to your OP (via you!) every time they 
render a page containing something attributed to you.

For other things it's more dubious than that, but the fact that it is 
technically possible means that at least some RP's will do it. I think 
it'd be a mistake to write the spec under the assumption that they won't 
unless we're going to include something that prevents it.

specs mailing list

HTTP Authentication Bindings for two-party OpenID Authentication

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

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.



specs mailing list

XRD-based Service Discovery - Draft 1

2007-03-03 Thread Martin Atkins

In respose to the discussion recently about modularizing the discovery 
part of OpenID Authentication 2.0, I've put together a possible first 
draft of a specification for doing service discovery using XRDS.

This document is really just the XRDS-related parts of Yadis but 
refactored slightly.

In particular:
 * XRI Resolution 2.0 is no longer required reading for implementors. 
Instead, it defines its own proper subset of XRDS/XRD which is 
completely defined within this document.
 * The various sentences referring to authentication services and 
specifically to OpenID, LID, etc. have been rewritten or removed.

My intention here is that the remaining parts of Yadis that are not 
included in this new specification will become XRDS Discovery for HTTP 

It'd be cool if it could be restructured in such a way that XRI 
Resolution 2.0 becomes only an informative rather than a normative 
reference, but as it currently stands it's used in conjunction with a 
couple of MUST clauses and therefore needs to be normative.

(I was going to put a more readable version of this on the wiki as well, 
but sadly it seems that OpenID login isn't working today... for me, at 

?xml version=1.0 encoding=utf-8?
?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?
!-- ?xml-stylesheet type='text/css' href='style.css' ? --
!-- * File Inclusion * --
!-- The parameter value is the name of the file to be included which can also be a URI. 
 In the case of local files the XML_LIBRARY environment variable provides a search
 path of directories in which the file may be located. See section 4.1.2 of README --
!-- include=n/a --

!-- * Rigor Control * --
!-- Try to enforce the ID-nits conventions and DTD validity --
?rfc strict=yes ?

!-- * Rendering Control * --
!-- Put the famous header block on the first page --
?rfc topblock=yes ?
!-- Include boilerplate from Section 10.4(d) of [1] (Bradner, S., The Internet Standards 
 Process - Revision 3, October 1996.) --
?rfc iprnotified=no ?

!-- Use anchors as symbolic tags rather than numbers for references --
?rfc symrefs=yes ?
!-- Sort references according to symbolic tags - irrelevant if symrefs=no --
?rfc sortrefs=yes ?

!-- Items useful for reviewing document --
!-- Render cref information --
?rfc comments=no ?
!-- If comments is yes, then render comments inline; otherwise render them in an 
 Editorial Comments section --
?rfc inline=no ?
!-- Insert editing marks for ease of discussing draft versions.
 Editing marks are strings such as 29 printed at the beginning of the blank line before
 each paragrpah of text. --
?rfc editing=no ?

!-- Items useful when using xml2rfc to produce technical documents other than RFCs and I-Ds --
!-- Produce a private memo rather than an RFC or Internet-Draft.
 The value of the PI is used as the title of the document.
 Omits the topblock and standard boiler plate when . --
?rfc private=Draft ?
!-- Override the center footer string --
?rfc footer= ?
!-- Override the leftmost header string --
?rfc header= ?

!-- * Table of Contents Control * --
!-- Generate a table-of-contents --
?rfc toc=yes ?
!-- Control whether the word Appendix appears in the table of contents. --
?rfc tocappendix=yes ?
!-- If toc is yes, then this determines the depth of the table of contents. --
?rfc tocdepth=3 ?
!-- If toc is yes, then setting this to yes will indent subsections in 
 the table-of-contents. --
?rfc tocindent=yes ?
!-- If toc is yes, then setting this to no will make it a little less compact. --
?rfc tocompact=yes ?
!-- Affects horizontal spacing in the table-of-content. --
?rfc tocnarrow=yes ?

!-- * Format Control * --
!-- Automatically force page breaks to avoid widows and orphans (not perfect). --
?rfc autobreaks=yes ?
!-- Put two spaces instead of one after each colon (:) in txt or nroff files. --
?rfc colonspace=no ?
!-- When producing a txt/nroff file, try to conserve vertical whitespace 
(the default value was no up to v1.30; from v1.31 the default is the current value 
of the rfcedstyle PI).
Will default to (rfcedstyle) in future. --
?rfc compact=no ?
!-- If compact is yes, then you can make things a little less compact by setting this 
 to no (the default value is the current value of the compact PI). --
?rfc subcompact=no ?
!-- An integer hint indicating how many contiguous lines are needed at this point in 
 the output.
 Can appear as many times as necessary in the source. --
!--  needLines=0 --

!-- * HTML Specials * --
!-- When producing a html file, use the image in this file.  --
?rfc background= ?
!-- Automatically replaces input sequences such as |*text| by,
 e.g., strongtext/strong in html output. --
?rfc emoticonic=no ?
!-- Generate mailto: URL, as appropriate. --
?rfc linkmailto=yes ?
!-- When producing a html file, produce multiple files for a slide show. --
?rfc slides=no ?
!-- When producing a html file, 

Re: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Martin Atkins
Dmitry Shechtman wrote:
 Then we'd publish in parallel the following two ancillary specifications:
 * OpenID Discovery for HTTP and HTTPS URIs
 * OpenID Discovery for XRI URIs.
 The latter being prepend to the XRI and use OpenID
 Discovery for HTTP.

I think as a starting point we should just refactor the existing 
XRI-related content from the Auth spec into a separate spec. We can then 
worry about simplifying it as a separate problem.

 Later, the OpenID community or a third party could publish a
 specification OpenID Discovery for Email Addresses, but I don't think
 we're really ready to go there right now.
 Could you please elaborate on this? I believe the SMTP Extension is pretty
 solid. The only thing it lacks is formality.

I'd rather not get into the debate about email-based identifiers here. 
This thread is about making it possible to have such a spec, not about 
which spec will be adopted and when. I encourage you to pursue this 
separately, assuming we actually do modularize the auth spec.

specs mailing list

Re: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Martin Atkins
rob wrote:
 Martin Atkins wrote:
 My proposal is that we make the core Auth 2.0 spec scheme-agnostic. It 
 would just state that an identifier is a URI. Later in the spec, where 
 currently it enumerates a bunch of ways to do discovery, it'd just say 
 do discovery on the URI using an appropriate protocol. (or, indeed, 
 words to that effect.) It would also nominate a standard XRDS service 
 type URI to use during Yadis discovery.
 can we also use the opportunity to put i-names support in an extension?

If this were to take the form I described in my original message, 
effectively *all* discovery mechanisms become extensions. The HTTP/HTTPS 
one gets special treatment by getting referenced by a MUST in the core 
spec, but it's still a separate document.

i-names would be handled as part of the OpenID Discovery for XRI URIs 
specification I mentioned.

specs mailing list

Re: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Martin Atkins
Drummond Reed wrote:
 I've always been supportive of breaking out OpenID Discovery into a separate
 spec. I wouldn't break it out into separate specs, however, because
 discovery for any OpenID identifier has have much more in common than they
 have different. For example, they all need to explain the relationship of
 the identifier being resolve to an XRDS document and the metadata needed to
 access other OpenID services.

My revised proposal is that the Authentication specification would 
include, as part of a Requirements for Discovery Protocols section, a 
section on the use of an XRDS document as part of discovery.

The separate discovery specs would then describe identifier recognition 
and canonicalization, how to retrieve an XRDS document and any other 
special non-XRDS mechanisms as appropriate.

So the HTTP/HTTPS one, for example, would:

* Describe How to recognise and canonicalize its identifiers
* Require the use of Yadis discovery to obtain the XRDS document
* Refer to the relevant section of OpenID Authentication for the XRDS 
processing rules.
* Require that if Yadis fails RPs fall back on the non-XRDS-based HTML 
discovery, describing how this mode returns the necessary information.

specs mailing list

Re: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Martin Atkins
Recordon, David wrote:
 Well there already is the Yadis spec.  Maybe the Yadis spec remains
 separate versus becoming part of the OASIS XRI Resolution document?

The XRDS-related parts of the Yadis specification seem to duplicate 
requirements from XRI Resolution chapter 3.

In the interests of avoiding redundancy, I'd suggest the following 
  1. XRI Resolution chapter 3 (or a separate spin-off spec) describes 
the syntax of an XRDS document.
  2. Yadis describes how to obtain an XRDS document for an HTTP or HTTPS 
  3. OpenID Authentication describes how to determine the endpoint URI 
and other information from an XRDS document, referencing [1].
  4. The new HTTP discovery specification would reference [2] and [3] to 
describe the XRDS-based HTTP discovery mode, and then go on to describe 
the HTML-based discovery fallback.

Alternatively, [3] above could be served by a separate spec OpenID 
discovery using XRDS, though I think that may be overkill for something 
so straightforward.

specs mailing list

Re: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Martin Atkins
Drummond Reed wrote:
 Under this approach, discovery all identifiers (URLs, XRI i-names/i-numbers,
 email addresses, phone numbers, etc.) would be handled by OpenID Discovery.

I disagree that a single spec can contain discovery rules for all 
conceivable discovery types without becoming ridiculously big. The 
discovery rules in the current spec for just handling HTTP/HTTPS and XRI 
discovery are already big enough.

However, I clearly have a bias for lots of small specs over one large 
spec, and clearly your bias is the opposite. :)

specs mailing list

Re: Modularizing Auth 2.0 Discovery

2007-02-28 Thread Martin Atkins

Having reflected on people's comments a bit, I have a slightly adjusted 
set of proposals.

  1. Take the bits about parsing XRD service elements from the Yadis 
spec and call it XRD service discovery for URIs.

  2. Have XRD service discovery delegate the actual mapping of a URI 
onto an XRD element to ancillary specs as before. These will define 
recognition/normalization rules for user input and how to take a 
matching URI and return an appropriate XRD element.

  3. Create XRD discovery for HTTP URLs which is really just the 
remaining stuff out of Yadis. *

 * HTML-based Discovery for OpenID remains a special case, but we 
can minimize the reach of this special case by stating in the HTTP URLs 
spec that if HTML-based discovery succeeds an implementation is to 
synthesize (or at least, act as if it synthesized) a 
functionally-equivalent XRD element containing Service elements for 
OpenID 1 and/or OpenID 2.

  4. Have OpenID Authentication 2 simply say “use XRD service discovery 
to find a service description for 
‘’ or 
‘’” and then…” and go on to 
describe the interpretation of the URI element and the LocalID element.

It'd also contain a special provision that RPs MUST support 
HTTP-based discovery, to retain the baseline functionality from OpenID 1.1.

The minimal reading for an OpenID Auth RP implementor then becomes:
 * Core OpenID spec
 * XRD service discovery
 * XRD discovery for HTTP URLs

While the idea of having three required specs is a little scary, these 
three should be able to stand alone and the latter two will be quite 
simple since they are just formed by splitting Yadis in half.

XRD discovery for XRIs barely needs defining since XRI resolution 
already covers most of it. Just need to bring over the 
recognition/normalization rules from the Auth Draft 11 section 7.2.


This also maps nicely onto a potential set of libraries:

  * 1 glue library that takes as input a URI and a list of service types 
in order of preference and returns an XRDS Service element representing 
the best match.
 findService(URI, serviceTypes[])

  * n discovery libraries which have three operations:
 isMyIdentifier(string) - determine if this library owns this
 normalizeIdentifier(string) - return a normalized version of the
 findXRD(URI) - retrieve an XRD element for the given URI.

 These are called by the glue library and then the glue library 
parses the returned XRD element.

  * 1 OpenID library which does:
  service = discovery.findService(=mart, [;,;,
  endpoint = service.getURI()
  localid = service.getLocalID() || =mart
  // etc, etc

specs mailing list

Re: Proposal for Modularizing Auth 2.0 Discovery

2007-02-28 Thread Martin Atkins
Gabe Wachob wrote:
 Basically, the Discovery Spec would specify that for any identifier scheme
 to work with OpenID, it MUST define a way of being constructed into an HTTP
 URI and then returning a XRDS with an HTTP GET on that HTTP URI. If there
 are other ways of resolving it, then implementations MAY use those other
 methods of resolution (native resolution, if you will). In essence, this
 is a requirement for HTTP gateway(s) to whatever resolution infrastructure
 exists today. 

I don't really think it's necessary to *mandate* that a HTTP mapping 
always be used. After all, it's very easy for a spec to, if it's 
appropriate, define a mapping to an HTTP URL and then reference the 
HTTP-based discovery spec.

While I agree that at this point any discovery protocol that *doesn't* 
use HTTP is going to face an uphill struggle as far as real-world 
implementations go, if people want to go ahead and try to get their 
off-the-wall protocols adopted I don't see any reason why we shouldn't 
let them.

specs mailing list

Re: HTTPS status

2007-02-28 Thread Martin Atkins
Alaric Dailey wrote:
 Eddy Nigg and I brought up the issue of requiring SSL  a while back, since
 then I have been swamped, it looked like there was some more talk about it
 since then.  
 I know that there are several other people, that are concerned about this
 too, and it has even been blogged about ( )
 Can someone please tell me the status on this? Hopefully its being required!

As far as I'm aware, the current status is:

  * All OpenID identifiers SHOULD use a secure channel.
  * All OpenID servers SHOULD use a secure channel.
  * OpenID relying parties MUST support SSL access to HTTP URLs.
  * OpenID relying parties MAY refuse to interface with identifiers and 
servers that do not use a secure channel.
  * All other connections are out of scope of OpenID Authentication.

I may be wrong on these, as I'm listing them from memory.

In practice, I expect all big OpenID providers will support SSL because 
users will demand it. The sites currently providing OpenID identifiers 
as value-add features alongside an existing service (LiveJournal, etc.) 
probably won't get used much once there are more proper providers.

People hosting their own identifiers and/or OPs probably won't use SSL, 
but then they won't be able to use their identifiers at any site which 
requires SSL-based OpenID Authentication, and they'll be in the minority 

specs mailing list

Re: [OpenID] Wiki page: Attempting to document the Email Address as OpenIddebate.

2007-02-12 Thread Martin Atkins
Hallam-Baker, Phillip wrote:
 Over time everyone will own their own DNS domain
  and it will form the hub of their personal
  communications system. All communication modes
  will map onto the single unified communication identifier.

I don't necessarily disagree with many of your arguments, but I wonder 
why — if everyone owns their own DNS domain — we even need the user@ 
portion anymore? Largely that was included because in the early days — 
and even today, for many people — their addresses were 

My primary personal email address (not the one I use for mailing lists) 
is pretty redundant since the part before the @ is the same as the part 
after the @ once the parent domain has been excluded. Leaving off the 
user@ portion doesn't make the address any less mine.

  An 'email' address is simply the conventional conjunction of a
  username portion and a DNS name portion. It need not be used only
  for email, nor is it. It is routine for people to use RFC822
  addresses for Jabber and other instant messaging applications.

Calling a Jabber ID an email address is a bit misleading. It's entirely 
possible for the email address [EMAIL PROTECTED] and the JID 
[EMAIL PROTECTED] to be owned/controlled by different people. It is not 
safe to assume that the two are the same person without evidence of 
that. What makes a string like [EMAIL PROTECTED] an email address is 
the fact that you can address email to it. The fact that the two 
addressing schemes use similar syntax doesn't help you much.

specs mailing list

Re: Proposal: An anti-phishing compromise

2007-02-09 Thread Martin Atkins
Recordon, David wrote:
 I agree that things like age should be in an extension, though I think
 this single piece of data is useful in the core protocol.  I'm sure the
 exact definition of phishing resistant will come back to bite us in
 sometime in the future, but lets deal with it then instead of not adding
 anything now.  I really like the idea that there be one thing in the
 core spec which reaches out to each extension.

I propose:


specs mailing list

OA2.0d11: Minor nit-pick regarding normalization

2007-02-01 Thread Martin Atkins


This is a really minor thing I just spotted due to leaving my browser 
open on the relevant part of the spec and coming back to it later. :)

The normalization table in appendix A.1 lists several examples of the 
normalization of URIs. The last few examples are as follows: = = =

I believe that the last example should instead normalize to:

* A HTTP URL without a path is a nonsense because the protocol doesn't 
allow for an empty path anyway. (You can't GET empty string HTTP/1.1)

* It's causes and to normalize to 
different strings, which is counter-intuitive.

* There is no useful reason to omit that slash except that the 
currently-specced normalization rules exclude it.

Therefore there should be an extra provision in section 7.2:

  * If the resulting identifier is an HTTP or HTTPS URL and it contains 
only the two slashes after the protocol specifier, an additional slash 
MUST be appended to the end of the string.

(not fussy on the exact wording.)

specs mailing list

Re: HTML parsing in HTML-based discovery

2007-01-26 Thread Martin Atkins
Claus Färber wrote:
 In order to facilitate regexp parsing, just requiring the start and end 
 tags is not enough. Additional restrictions may also be necessary to 
 avoid cases where too simple regexp-based parsers might fail:
 - head start with attributes.
 - order of attributes within the LINK tag.
 - single quotes vs. double quotes vs. no quotes.
 - unescaped / within attributes.*
 - numeric character references.*
 - line feeds within tags.*
 - additional XML namespaces that allow attributes like foo:href.*
 - LINK tags within !-- comments --.*
 - [to be continued]
 (* = inspired by a real-world implementation failing to handle these 
 cases correctly)

And, in theory, the OpenID spec could add additional restrictions to 
fix the above problems.

Whether it should or not is of course up for debate; I'd be interested 
to hear from Brad Fitzpatrick and JanRain's developers who are 
responsible for the most-used implementations currently using regex 
parsing. Why didn't you guys use an HTML parser? I assume there must 
have been a reason.

 This is mostly an ideological argument founded on whether we're allowed 
 to impose additional restrictions on HTML documents that are making use 
 of OpenID discovery. There is certainly no *practical* reason why this 
 shouldn't be done, assuming that the restrictions are sufficient to 
 prevent the above attack.
 There are practical problems:
 * Users can't use existing HTML tools to check for the additional
restrictions. A validator will say valid HTML but the OpenID
login fails due to a parsing error (e.g. the PHP implementation used
on OpenID Enabled). And different RP will choke on different things.

An HTML validator also won't help them if they transpose the values of 
openid.server and openid.delegate, or if they type rel=opnid.server 
instead. There are OpenID-specific validation/checking tools in the 
works which will hopefully be able to give users good information about 
potential pitfalls with the way they have written their HTML in addition 
to pointing out things like that the openid.server LINK is missing.

 * Users can't use existing HTML tools that do not honor the additional
restrictions. A HTML pretty-printer may simply re-format the code in
a way unparsable by ad-hoc parsers; a hypothetical htmlcrush program
might may remove the optional quotes, entity references and tags in
good faith.

Indeed. But those documents wouldn't conform to the OpenID 
specification. (assuming that it went into more detail about the 
restrictions it is adding to HTML.)

I think the main point here is that despite the outcome of this debate 
people *will* write regex-based parsers, whether the spec allows for it 
or not. We have a choice between ignoring the issue so that all of these 
regex-based parsers fail in interesting ways on odd cases, or accepting 
that this is inevitable and listing in detail a set of rules for 
regex-based parsing in addition to a set of restrictions on HTML that 
make those parsing rules possible.

I'd love it if everyone would use proper HTML or XML parsers, but that 
just isn't going to happen no matter how much we wish it would. In the 
end almost there but not quite implementations hurt no-one but the 
end-user, and OpenID is what will get the blame for any negative user 
experience, not the libraries that use incompatible regex-based parsers.

specs mailing list


2007-01-25 Thread Martin Atkins

Since your list is long, I'm only going to address things I have an 
answer to. I'll leave the rest to other people. :)

Claus Färber wrote:
 | 4.1.1.  Key-Value Form Encoding
 | A message in Key-Value form is a sequence of lines. Each line begins
 | with a key, followed by a colon, and the value associated with the
 | key. The line is terminated by a single newline (UCS codepoint 10,
 | \n). A key or value MUST NOT contain a newline and a key also MUST
 | NOT contain a colon.
 While it's ok for keys to have a limited alphabet, not allowing them in
 the value may be a problem for future extensions (say, if AX wants to
 transfer a multiline postal address).
 I don't think it's a good idea to invent a new format here. What's wrong
 with URI percent-encoding, which has to be implemented by OpenID
 software anyway?

As far as I'm aware the protocol does not allow for extensions to add to 
the messages sent in this encoding. Extensions are only allowed to take 
part in the messages passed by redirecting the UA, in urlencoded format. 
The OpenID protocol itself has no need for newlines or other fancy 
characters here.

I agree with you that inventing a new format here was an odd choice, but 
unfortunately it's already in use by deployed OpenID 1.1 implementations 
and so OpenID 2 implementations will have to support it anyway.

 | The response body MUST be a Key-Value Form (Key-Value Form Encoding)
 | message with the following fields:
 | *error
 | Value: A human-readable message indicating the cause of the error.
 What about different languages?
 This is actually tricky. The Accept-Language header from the user is not  
 available to the OP if it is contacted by the RP directly, so the OP  
 can't choose an appropriate language.

This human-readable message is really addressed at the developer of 
the non-compliant implementation, not the end-user. Therefore support 
for multiple languages was thought not to be that important. All current 
implementations use straightforward English messages.

The end-user should never see such a message since these error responses 
only arise when there is a bug in someone's implementation. (In theory, 
at least!)

 | 7.3.3.  HTML-Based Discovery
 | HTML-Based discovery MUST be supported by Relying Parties. HTML-Based
 | discovery is only usable for discovery of Claimed Identifiers. OP
 | Identifiers must be XRIs or URLs that support XRDS discovery.
 | To use HTML-Based discovery, an HTML document MUST be available at the
 | URL of the Claimed Identifier. In the HEAD section of the document:
 It seems that it has been unclear to some implementers what HEAD
 section means. This is not surprising as the correct term is HEAD
 element (HTML 4.01, section 3.2.1).

Agreed. This is just a simple language change.

 |A LINK tag MUST be included with attributes rel set to
 |openid2.provider and href set to an OP Endpoint URL
 |A LINK tag MAY be included with attributes rel set to
 |   openid2.local_id and href set to the end user's OP-Local
 |   Identifier
 These should read LINK element, not LINK tag.

While you're correct, I don't think it's that erroneous to say LINK 
tag here. Still, it can't hurt to correct it.

 | The protocol version when HTML discovery is performed is http://
 | The host of the HTML document MAY be different from the end user's
 | OP's host.
 | The openid2.provider and openid2.local_id URLs MUST NOT include
 | entities other than amp;, lt;, gt;, and quot;. Other
 | characters that would not be valid in the HTML document or that cannot
 | be represented in the document's character encoding MUST be escaped
 | using the percent-encoding (%xx) mechanism described in [RFC3986]
 | (Berners-Lee, T., Uniform Resource Identifiers (URI): Generic
 | Syntax, .).
 This is incompatible with HTML parsing rules.
 I think the whole section is flawed and should be replaced with a small
 note as a warning:
   Note: If the openid2.provider and openid2.local_id contain an
   ampersand (), this character MUST be escaped as amp; according to
   HTML rules.

In practice, few implementations actually use an HTML parser to find 
these elements. These extra restrictions are present to facilitate 
regex-based parsing.

Since there is no regression if an implementation should choose to use a 
*real* HTML parser, I don't see the harm here. It's imposing extra 
restrictions only on people who want to use OpenID HTML discovery; the 
rest of the document uses the normal HTML rules, though there is one 
exception which I'll describe below.

 BTW, good HTML parsers are mandatory to protect against HTML injection
 attacks. An ad-hoc parser might simply fall for something like that:
   link rel=openid2.provider href=''
   titleNice test/title
   form action=doit
   pSend me your comment:

Re: Service Type Namespaces

2007-01-05 Thread Martin Atkins
Recordon, David wrote:

These seem just fine to me.
(+1, I guess!)

 So very verbose and organized.  There is no need for an xmlns for the
 Auth 2.0 spec itself, since unlike the 1.1 spec which defined
 OpenID:Delegate in Yadis, 2.0 takes advantage of the LocalID element
 already defined in the XRD schema.

I missed the change to using LocalID. I'm glad to see that change, but 
really just because I've always hated the fact that it was called 
Delegate in Yadis. :)

This naming scheme doesn't separate out extensions by what they're 
extending. Presumably in future we're going to have other non-extension 
specs (that is, they don't actually use the OpenID Authentication 
request as a transport) which will themselves have extensions.

How about,

I've not got my heart set on abbreviating extensions, but I don't 
really like URLs that are longer than one line in a plaintext email 
because then people start wrapping them over multiple lines. :)

specs mailing list

Re: OpenID Exchange

2006-12-15 Thread Martin Atkins
Recordon, David wrote:
 Awesome, glad to see this!  Would be great as Johannes said to see some
 flow examples and how you'd see it integrate to do something like
 exchange profile data or post a photo on your blog.  Would love to see
 this formalized and happy to help however I can!

I'm hoping to get some working demo examples done this weekend in some 
form or other, if I get time. Failing that, I'll at least try to get 
some written, theoretical examples written up for the scenarios I listed 
in my original message.

specs mailing list

Re: [OpenID] Assertion Quality Extension = openid.importance

2006-12-13 Thread Martin Atkins
Manger, James H wrote:
 A related hassle is that when my OP supports a new authentication method 
 (such as a strong password-authenticated key agreement scheme (eg SRP)), 
 existing RPs will not recognize this method as strong enough for the RP’s 
 expectations – regardless of the method’s actual strength.

Consider also that non-human agents can often be both the OP and the 
user at the same time (they specify a URL under their own control as 
the OP, generate their own signature and respond) and in this case the 
OP knows that the user is the user without any shadow of a doubt because 
it *is* the user. However, this scenario would fail in any situation 
where a particular authentication scheme is demanded because there is 
*no* traditional authentication in this scenario.

However, if the RP instead presents (for example) a list of keywords 
identifying (in vague terms) what is at stake:
 transaction_involves=money+personal_details non-human agent can pick up that it's being used for something for 
which it is not intended and refuse to take part. My traditional OP, on 
the other hand, can present me with a set of options (with reasonable 
defaults) for what to do in the presence of these keywords so that 
anything involving money can force a re-authentication (again, for example).

Whether a list of keywords is the way to go remains to be seen, but I 
believe this is the most sensible approach in principle.

specs mailing list

Re: [OpenID] Assertion Quality Extension = openid.importance

2006-12-13 Thread Martin Atkins
Justin S. Peavey wrote:
 I fully agree with you in your example above until you mention money. 
 In the Amazon example for book purchases, the user is not the one
 affected by a mis-authenticated transaction, Amazon and the credit-card
 companies are; the user is indemnified by most credit card companies for
 fraudulent purchases.  If the user was *actually bound* to be
 responsible for the transactions their identities perform, the model
 works - but this is not the world that I (or Amazon, or Bank of America)
 live in. 

Is anyone really expecting an OpenID identity to be used in place of a 
credit card number? Perhaps I'm just not seeing the advantage of this, 
but I would expect that most organizations carrying out credit card 
transactions would:

  * Use OpenID to authenticate the user against the account to gain 
access to the purchase history, returns, enquiries and such.
  * Demand the user's credit card before actually performing any 

While I'll admit that Amazon and PayPal currently store credit card 
details and require (in some cases) only the password to be entered, it 
can hardly be argued that my Amazon password is any more secure than my 
IdP password. In Amazon's case they still don't let you make a purchase 
knowing only the password in most cases; you have to provide all or part 
of the stored credit card number or other authentication details.

But this is all beside the point given the fact that the OP *is always 
in control* — there is NO WAY that the RP can tell what the OP really 
did. The OP can lie, the OP can have a bad implementation of a given 
authentication scheme or the OP might not even be a traditional OP at 
all. I don't really see the value in presenting a protocol which gives 
an illusion of control to the RP; it just seems dishonest.

specs mailing list

OpenID Exchange

2006-12-13 Thread Martin Atkins

I have made an early draft of a spec called OpenID Exchange on the wiki:

The goal of this protocol is to allow user-accompanied HTTP requests. 
user-accompanied means that a consumer makes a request to a service on 
behalf of a user and the user reviews and approves the request.

Example applications of this include:
  * Zooomr posting photos into your blog with your one-time approval, 
without disclosing your login credentials. [1]
  * Fetching of user profile information.
  * Social networking friendship handshakes. [2]

The protocol should, in theory, be able to act as a transport for any 
HTTP-based protocol such as SOAP and AtomAPI, as well as for simple GET 
requests. The protocol for post in my blog could, for example, just be 
an AtomAPI POST request made over OpenID Exchange.

This is still work-in-progress. The spec needs lots of refinement and at 
some point I'll have to make a demo or two.

[1] You can still see the results of the demo of my earlier version
of this on LiveJournal, albeit without the pictures:

[2] Discussed further in my blog entry on social networking:

specs mailing list

Re: Consistency of negative responses to checkid_immediate requests

2006-12-13 Thread Martin Atkins
Josh Hoyt wrote:
 It's confusing to me make the failure response to an immediate mode
 request be id_res, especially if that is not the failure response
 for setup mode. I can't see a reason that they can't both use the
 cancel response to indicate that the OP or end user do not wish to
 complete the transaction.
 This is a very minor change, but it will make the spec simpler.

I think the RP will want to do something different in these two cases. 
In the cancel case (which indicates that the user cancelled the 
request in some way) the RP will probably return to the login form to 
invite the user to try again.

In the checkid_immediate case, what needs to happen is that the RP must 
start a checkid_setup request instead, since a negative response in the 
checkid_immediate case generally means I can't answer this until I've 
presented some UI to the user.

I suppose it could be argued that the RP should know what it's doing and 
be able to distinguish between these cases using its own state, but 
given that the meaning of these responses is different I don't think 
it's a problem that the messages are different.

It'd might be nice if the checkid_setup error response were called 
something other than id_res, though.

specs mailing list

Re: [OpenID] Assertion Quality Extension = openid.importance

2006-12-12 Thread Martin Atkins
Manger, James H wrote:
 The user-centric solution is not for the RP to specify a max auth age (or 
 captcha or email verification or handbio or hardotp…), but for the RP to 
 indicate the importance of the authentication. The user (with a little help 
 from their OP) decides how to react (eg whether or not to login again) based 
 on the importance/RP/auth-age/….

I like this approach a lot more. It seems a lot more honest as to what's 
really going on, and it leaves protecting the task of user's interests 
in the IdP's hands where it belongs.

specs mailing list

Re: [OpenID] Assertion Quality Extension = openid.importance

2006-12-12 Thread Martin Atkins
Paul Madsen wrote:
 Is there not a potential contradiction between an RP expressing both of 
 'this is very very important to me' and 'I leave it to you as to the 

Perhaps, but that is the case in both the IdP reports and the RP 
suggests case: either way the IdP is calling the shots, but the RP 
suggests case is more honest about who is in control.

specs mailing list

Re: OpenID IPR Policy Draft

2006-12-07 Thread Martin Atkins
Recordon, David wrote:

Is it really possible to use mailing list subscription as a trigger for 
a contract like this? The whole idea scares me a little bit, to be honest.

It seems more sensible to me to put these restrictions on actual 
*contributions*: require that any proposal or concrete 
specification/implementation offered via the mailing lists or other 
official channels to come with patent disclosure, and only *then* are 
any undisclosed patents assumed to constitute a royalty-free, perpetual 

As it is currently written, I think lots of companies that retain 
software patents of any kind — or even ones that don't but may wish to 
in the future — would be put off contributing due to the risk that their 
patents may be implicitly licenced to everyone.

I'm not a lawyer, of course. However, not everyone who could potentially 
be affected by this is a lawyer either, so putting in stuff that 
potentially scares non-lawyers like myself is probably a bad idea.

specs mailing list

Re: Yet Another Delegation Thread

2006-10-25 Thread Martin Atkins
Pete Rowley wrote:
 Actually I think this is a consequence of using URLs as identifiers and 
 wanting to use my site to host the portable identifiers - you're 
 probably thinking separate domains per portable identifier or using some 
 well known IdP. Each identifier can be correlated by inference in this 
 case since they are on the same site. Non-correlatable identifiers would 
 need to either be on separate sites or be hosted as a service and 
 thereby taking advantage of the lost in the crowd effect.

This is true, but this is an implementation decision you can make for 
yourself. If you want to make an identifier that has no links to any of 
your other identifiers, there's no reason why you can't choose to use an 
arbitrary IdP-issued identifier that has no connection with any others. 
You lose the identifier portability, but this is a trade-off you must 
make on your own.

specs mailing list

Re: Yet Another Delegation Thread

2006-10-25 Thread Martin Atkins
Dick Hardt wrote:
 The RP can't trust state that it has sent to the IdP since the  
 message may have been modified in transit between the RP and the IdP.
 Perhaps someone can explain what state needs to be maintained? And if  
 the RP wants to put state in the message, I thought we had that as  
 data in the return_to? The RP likely needs to sign that in some  
 manner to know that it was not modified as well.

The current stateless RP implementations just repeat discovery when they 
get back the signature. There is therefore a slim chance that the 
request had been modified to change the claimed_identity to another 
identifier owned by the same user and delegated to the same IdP 
identifier at the same IdP. However, aside from this rather odd attack 
the second discovery is sufficient to avoid the need for RP state or 

specs mailing list

Re: Two Identifiers - no caching advantage

2006-10-22 Thread Martin Atkins
Dick Hardt wrote:
 On 21-Oct-06, at 10:52 PM, Josh Hoyt wrote:
 On 10/21/06, Dick Hardt [EMAIL PROTECTED] wrote:
 2) the RP does not verify the binding between the portable
 identifier and the IdP-specific identifier in the response.
   to the one the attacker controls and the IdP has mapped
 This is the part where I think you're wrong. The RP MUST verify that
 binding, whether it is by keeping state, self-signing the request
 (which gets passed through to the response) or doing discovery again.
 I agree the RP SHOULD do that. The proposal does not specify that.
 I thought we had that conversation. I have not looked at the patch  
 that you sent. Perhaps you address the issue there.
 My point though is: why have the RP bind the IdP-specific identifier  
 and the public identifier? Why not let the IdP be responsible for this?
 In 1.x when the IdP was not aware of the public identifier, then the  
 RP had to do the binding. Now that the IdP is aware of the public  
 identifier, it would be simpler and logical for the IdP to be  
 responsible for the binding. It is doing it anyway.
 All the RP wants is which public identifier is the user, and is the  
 IdP authoritative for it.

If delegation is going to require cooperation from the IdP anyway, 
there's no longer any value in having the distinction between a public 
identifier and an IdP-local identifier. The hypothetical IdP 
IdP-tastic can just store a relationship between and my user account at IdP-tastic. There's 
no need for anymore, and with that gone 
delegation is no longer useful: the public identifier, whatever it might 
be, is the only identifier.

Any disadvantages to uniting the public identifier and the IdP 
identifier are also disadvantages of having the IdP do the binding as 
you describe. For simplicity's sake, I'm currently only willing to vote 
positively for one of the following scenarios:

* Have only one identifer in the protocol. Remove delegation entirely. 
IdP maintains relationships between arbitrary identifiers and its local 
user accounts. IdP no longer needs to issue its own identifiers, though 
it can if desired. This makes life simpler for RPs, but has the risk 
that delegation would become an IdP premium feature, which may hurt 
users in the long term.

* Protocol has two distinct identifiers: public and IdP-local. Relying 
party manages delegation. IdP does not even know that the delegation has 
taken place and has no way to stop it happening [1]. RP now has to do 
more work, but identifier portability now comes for free.

Having the IdP deal with the public identifier while still keeping the 
IdP-local identifier (and thus delegation) is, it seems to to me, 
muddled nonsense; the whole purpose of delegation was to make these 
identifiers distinct.

[1] Conceivably a mischievous IdP could make use of knowledge of how 
particular RPs round-trip their delegation state to block it, but that 
would be an arms race in the RP's favour rather than a designed-in 
mechanism for detecting delegation.

specs mailing list

Re: OpenID Login Page Link Tag

2006-10-20 Thread Martin Atkins
Drummond Reed wrote:
 I initially agreed as well. But to play devil's advocate, the link-to-XRDS
 option could actually be pretty efficient. Any HTML page could simply
 advertise the availability of its Yadis XRDS file using an XRDS link in the
 header. Assuming that many or all of the pages on a site would be covered by
 the same XRDS file, the browser would only need to download it once to cover
 the entire site. The XRDS would expire (using the same cache control that
 XRI resolvers use) and be refreshed as needed.
 This is the architecture that P3P used
 The XRDS file could provide discovery of multiple services representing the
 RP, not just the login page.

This is not incredibly different to what happens when you have a 
site-wide CSS stylesheet. In fact, it is possibly *better* than that 
situation since you don't need to delay page rendering while waiting for 
the Yadis document to download.

I wonder, though, whether we are asking too much of browsers' plugin 
interfaces? This is an honest question, as someone who's never written a 
browser chrome plugin before.

I guess IE's ones are just COM objects and can thus do whatever they 
like, but what of Firefox? Chrome overlays? Does that mean that they can 
access the HTTP component somehow to make HTTP requests?

I think Opera's pretty unlikely as it has no real plugin interface to 
speak of. I have no idea at all about Safari.

Anyone care to elaborate? There's no point in speccing something that's 
unimplementable, but it's probably okay as long as IE and Firefox can do 
it; the others can just catch up later.

specs mailing list

Re: Discussion: RP Yadis URL?

2006-10-16 Thread Martin Atkins
Recordon, David wrote:
 I'm torn if this parameter should be added to the spec at this time or
 not.  Adding the parameter is conceptually simple, though I don't think
 there is agreement on what the RP should be publishing in their Yadis
 file.  There is the section which
 has the RP publish a return_to URL, though the section was meant to be
 removed as that URL may not be the right entry point to start a

I would say that what's inside the Yadis document is outside the scope 
of OpenID Auth. It's simply a hook to enable extensions that must be 
instrumented at the RP side.

In other words, OpenID auth just needs to specify how to find an RP's 
Yadis document. The rest is for other people to figure out. That is the 
point of Yadis, after all.

(and then this IdP-initiated login thing could be an extension built 
upon this ability, and thus not hold up Auth 2.0.)

specs mailing list

Re: Identifier portability: the fundamental issue

2006-10-16 Thread Martin Atkins
Chris Drake wrote:
 There seem to be a lot of people on this list who want to hate and
 loathe the IdP, and grant all power to the RP.  I do not understand
 this reasoning:  our users will select the IdP they trust and like,
 then they will be using a multitude of possibly hostile RPs
 thereafter: the reverse is simply not true.

If I'm using one IdP to assert my primary public identity, they can 
hypothetically develop quite a profile about me. I probably don't mind 
too much in most cases, because I researched them and found that they 
are a good provider and won't sell my data out to the bad guys.

However, there might be some things I want to do (for example, posting 
locally-prohibited speech on a public forum) that I don't want attached 
in any way, shape or form to my public identity. The trust relationship 
I have with that IdP probably isn't enough for this; if there is any 
record at all of any association between these two identities, as 
friendly as my IdP may be, there is a chance that it will be ceased by 
court order, or leaked by an insider, which might lead to me getting in 
serious legal trouble.

This is just one (perhaps extreme) example of why my trust in my IdP is 
not universal and all-encompassing. Trust is not a boolean.

specs mailing list

Re: Identifier portability: the fundamental issue

2006-10-14 Thread Martin Atkins
Brad Fitzpatrick wrote:
 Counter-argument:  but OpenID 1.1 does have two parameters:  one's just in
 the return_to URL and managed by the client library, arguably in its own
 ugly namespace (not IdP/RP managed, not openid., but something else...
 the Perl library uses oic. or something).  So then it's harder to
 document the correct behavior to people (RPs should verify the mapping
 when you get a signature!) because the parameter names aren't consistent
 between RP clients.

Not specifying it gives RPs the freedom to put whatever handle they want 
in the return_to, though. If they *are* able to maintain state, they 
might have some arg like ?handle=1380a383198bcefd933, which is 
completely opaque to everone except the RP.

I'd rather avoid specifying things we don't need to specify, since it 
leaves more flexibility for implementors in an area where this 
flexibility doesn't do any harm.

specs mailing list

Re: Consolidated Delegate Proposal

2006-10-13 Thread Martin Atkins
Dick Hardt wrote:
 Won't the IdP will still have to resolve the i-name? The IdP can't  
 trust the RP, or know that the i-name and i-number are really linked  
 unless it checks itself.

The IdP is only authenticating the i-number. The i-name is for display 
to the user and possibly to allow the user to choose that as the display 
identity to send back to the RP. The only attacks possible are:

* RP tries to fool the user into authenticating as a different 
i-number by sending a false i-name. I'm not sure what the benefit of 
this attack would be for the RP.

* The RP tries to convince the IdP to send back an incorrect display 
identity back in the response. But then the RP is just fooling itself!

The spec should probably contain some words to say that the IdP should 
not do any processing on the public identifier (whether it be a 
delegated HTTP URL or an XRI) that relies on the i-name to i-number 
mapping without first ensuring that the mapping is correct; any such 
processing would be outside of what is required for the Auth spec, though.

Assuming for the moment that we've conceptually separated the public 
identifier from the IdP token per my proposal, the public (delegate) 
identifier or i-name is for the RP (it checks the mapping), and the IdP 
token (which is some URI that doesn't necessarily even have to be 
resolvable) is for the IdP. Both parties validate their own token; if 
either party doesn't validate its own token, it opens itself up to the 
other party telling lies. However, they do not have to authenticate 
*each-other*'s tokens.

The RP's validation of its own token is defined by the spec. The IdP's 
authentication is not defined by the spec; the IdP doesn't necessarily 
even have to resolve its own tokens, but it can do if it wishes.

 Lastly, in the case where the identifier-the-RP-stores and the
 identifier-the-IdP-stores are different, if the RP has already  
 the latter, then the RP can be stateless by sending both to the  
 IdP, knowing
 it will receive both back in the response.
 Then the RP is trusting the IdP will send back a correct mapping.

This one bothers me too. Unless the RP can sign its initial request 
parameters to stop the IdP from tampering with them, I don't see how the 
RP can trust the IdP to return a correct mapping.

My old stateless RP demo implementation just re-resolved this stuff when 
it got back the response to make sure that the IdP was telling the 
truth. I'd love to hear that this was unnecessary, since it did double 
the identity resolving overhead.

 This discussion has me wondering about XRI resolution though. Given  
 that multiple i-names can resolve to the same i-number, just as  
 multiple domain names can resolve to the same IP address, and that  
 the i-name is the identifier the user sees, it would seem tht the i- 
 name is what should be stored by the RP, otherwise there is no  
 difference between using any of the i-names that resolve to the same  
 i-number, or is that the idea?

I think this is the intention, though it does show an interesting 
inconsistency between the use of XRIs and the use of i-numbers. I 
currently have three URL-based identifiers all pointing at the same 
server and the same Yadis document, yet those identifiers are distinct. 
However, in the comparable XRI case, it would appear that those 
identifiers would all be considered to be the same.

I wonder how easy it is to get hold of new i-numbers. If they are 
basically throw-away cheap, then I'm able to decide for myself how to 
distribute my mappings to separate them. However, if these i-numbers are 
going to be expensive (for some sense of the word) to aquire, I've got 
less freedom in this respect. Drummond?

specs mailing list

Re: Delegation discussion summary

2006-10-13 Thread Martin Atkins
Drummond Reed wrote:
 +1 to getting it done. This area of terminology is more a 
 usability/marketing issue at this point. I agree we need to converge on 
 good, simple user-facing terms for describing OpenID in ways ordinary 
 Web users can easily understand. Although I have great respect for Dick 
  Sxip’s pioneering work in this area, I don’t believe terms that use 
 the word “site” are the right metaphor, and the concept of “membersite”, 
 while good for the context Sxip originally used it, would send the wrong 
 message about OpenID.
 But I suggest we move that terminology discussion to the marketing list.

What marketing list?

specs mailing list

Re: [PROPOSAL] request nonce and name

2006-10-13 Thread Martin Atkins
Marius Scurtescu wrote:
 On 12-Oct-06, at 5:07 PM, Josh Hoyt wrote:
 On 10/12/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
 If passing through all unrecognized parameters can cause problems
 then there could be a special namespace for this purpose. For
 example, all parameters with names starting with openid.pass. should
 be ignored by the IdP and passed back to the RP.
 Yahoo Browser-based authentication [1] has a single parameter called
 appdata (that you can find in [2]) that is used for this purpose.
 This seems general enough to me.
 True, even one single pass through parameter should do.

This causes the minor inconvenience that the RP will probably now have 
to implement its own parsing, rather than using the framework's 
pre-supplied functions for dealing with urlencoded query strings.

Not a major deal, but I'd guess that this is where the idea to use 
return_to args came from in the first place.

specs mailing list

Re: [PROPOSAL] request nonce and name

2006-10-12 Thread Martin Atkins
Recordon, David wrote:
 We thus believe that any state tracking needed by a stateless RP must be 
 maintained as GET parameters within the return_to argument.  In the case 
 of a stateful RP, it can either do the same thing, or store state via 
 other means such as using a session id within a cookie to reference 
 database data.

Sounds good to me.

specs mailing list

Re: Consolidated Delegate Proposal

2006-10-10 Thread Martin Atkins
Recordon, David wrote:
 It is needed in the case where there is delegation with a URL,
 openid.identity is the actual URL on the IdP and then openid.rpuserid is
 the URL that the user entered which delegates to openid.identity.  This
 is then also used in the similar case with XRI delegation.

Does the IdP really need to know what URL I gave to the RP?

Earlier versions handled this adequately by the library including 
implementer-defined variables in the return_to URL, which allows a 
stateful RP to hide the real identifier behind a meaningless session 
token, which satisfies Brad's criteria that the RP should be able to 
hide from the IdP the fact that delegation is in use.

specs mailing list

Re: Strong Authencation (was [PROPOSAL] authentication age

2006-10-06 Thread Martin Atkins
Chris Drake wrote:
 Hi All,
 1. Amazon asks the IdP Please assert this user is not a Robot
How can it trust this occurred?
 2. Amazon asks the IdP Please re-authenticate this user, via
two-factor, two-way strong authentication
How can it trust *this* occurred?
 The IdP can *say* it did, but would RPs prefer a stronger role to
 encourage adoption? (eg: #1 - the RP provides the captcha, and the
 hash of the solution, while the IdP returns the solution, or #2 - the
 RP provides a nonce and later looks for this nonce in the IdP's
 also-signed-by-the-authentication-vendor-technology response)
 i.e.: It might get ugly to try and add this stuff in later if we've
 not catered up-front for these kinds of interchanges.

These use-cases seem like a good one, in that it's something that's 
actually *verifiable*, rather than relying on a trust relationship that 
probably doesn't exist between RP and IdP.

I still don't think this should be in the core spec — core OpenID Auth 
should be simple — but we should make sure that it's possible to add it 
via extension and if it isn't adjust the way extensions work to make it 

specs mailing list