Re: section 11. Verifying Assertions

2008-07-28 Thread Kevin Turner
See section 11.4.2.  Verifying Directly with the OpenID Provider.

or encode your state in a signed cookie or the return_to URL or somesuch.
specs mailing list

specs and implementations (Re: Problems with OpenID and TAG httpRange-14)

2008-03-21 Thread Kevin Turner
On Fri, 2008-03-21 at 09:38 -0700, Will Norris wrote:
 Regardless of what specific spec addition we're talking about, I don't
 think the technical difficulty to implement it should ever be a
 determining factor in weighing the merit of the proposal.

I disagree here.  We don't write specs just so people can appreciate the
abstract beauty of the models we describe.  We write specs so we can
have working code solving problems.  No specification should be
considered complete without at least one reference implementation, and
the complexity of implementation should be taken as feedback to the
developing specification.

The more complexity is required, the more expensive it is to implement
and test the specification, which directly impacts adoption.  And the
more error-prone the implementations will be, hampering

I think this idea is fairly central to OpenID.  As others have pointed
out time and time again, there are other systems that have pretty much
all the same properties as OpenID does, they may cover them in a more
rigorous fashion, they may have been around for years or decades, but
they don't have the appeal that OpenID does today.  I believe that is
because they were perceived as too inaccessible, or too expensive to
implement or integrate.

I'm not saying that Noah's proposed change is in any way impossible to
implement, but as a member of a team which maintains three OpenID
implementations, the cost is going to be a factor for me.  Most (if not
all) of the editors of the OpenID specification(s) to date have been
directly involved in implementation, and I doubt I am alone in this.

(And yes, I do recognize that I have, in the past, argued in favor of
things that were a lot more complex than this.  It's one factor among

 - Kevin

specs mailing list

Re: Problems with OpenID and TAG httpRange-14

2008-03-19 Thread Kevin Turner
On Wed, 2008-03-19 at 23:54 +0900, James Henstridge wrote:
 The fact that some sites incorrectly resolved the redirect to
 /about/ is probably due to the non-standard response headers for -- it contains a relative URI reference in the
 location header, while the spec requires an absolute URI.
 Do you have more information about which sites exhibit which
 behaviour?  Or better yet, which libraries they are using?

The current behaviour of all libraries would be to

a) fail, due to the relative Location header (this may depend on what
http client backend is used), or 

b) normalize that as

given Johnny's earlier comments, I expect that openid4java behaves the
same way, and I'd expect the same from the -- well, I was going to say
early Perl implementations, but really, I can't think of an
implementation that I *wouldn't* expect that behaviour from.  (Unless
perhaps Noah or Sam Ruby have written their own implementations.)

And my hunch is that the implementation which resolved it as did so not because it was honoring 303 vs 302 semantics,
but because it wasn't properly normalizing with redirects at all. (I'd
happy to be shown wrong on that count.)

specs mailing list

Re: Difference between 1.0 and 1.1

2008-03-12 Thread Kevin Turner
On Wed, 2008-03-12 at 16:28 +0200, techtonik wrote:
 But 1.1 OpenID server doesn't know anything about openid.ns, because
 it was added only in 2.0  Therefore server fails to authenticate and
 this should be considered a bug in consumer, which should not send
 openid.ns at all. If everything above is right then where is the logic
 and what are the reasons for consumer to send
 openid.ns=; at all?

Yeah, we discovered that there are people sending openid.ns with v1
messages to myOpenID.  I think the case where this happens most is when
someone has set up their own page with version 1 style delegation, with
a openid.server link instead of openid2.provider.  Then you can get
a v2-capable RP talking to a v2-capable OP, but since the delegation
format is stale, they use v1 messages.  Whereas a real v1 OP may well
just ignore openid.ns, because it didn't exist, this ns-aware
v2-capable OP tries to inspect it to see what version it is...

and the fact that there are *two* namespaces in the v2 spec for v1
OpenID is sort of a disaster, but both of them are being used in this
way now.  (Drupal was sending whichever one I wasn't expecting...)

specs mailing list

Re: Question on Association Secrets

2008-03-11 Thread Kevin Turner
On Mon, 2008-03-10 at 11:27 +0100, Oliver Welter wrote:
 1) Is an individual session dedicated to an Identifier/OP Combo, or is a 
 secret/session used for different Identifiers which are served by the 
 same OP?

Associations are for a pair of (RP, OP), usable for any communication
between them regardless of identifier.

 2) Is support of No-Encryption over TLS mandatory for each RP?

An RP that does not work when asked to communicate with an HTTPS
endpoint does not have a fully compliant installation of the protocol.
However, there do exist a number of these installations in the wild.

specs mailing list

Re: OpenID 2.0 finalization progress

2007-10-22 Thread Kevin Turner
On Fri, 2007-10-19 at 16:12 -0700, Johannes Ernst wrote:
 [...] and after they had produced a spec, Rambus said but we have
 some patents. This lead to at least one lawsuit I believe.
 I have heard wildly diverging assessments on whether or not this  
 could happen here.

Ok, I'm looking for the devil's advocate here, so let's assume the
worst.  Say we call the spec final now, and then sometime in the next
forty days, a problem like that comes up.  What are the consequences of
that?  Specifically, do any of the solutions to that hypothetical
problem involve changing the spec?  In what way?

The way I understand it, right now one of two things happens:

1) Things go more-or-less smoothly now.  The IPR policy may get tinkered
with a little bit during the review period but this does not influence
the technical specification.

2) The sky falls and we decide that there is no IPR policy that can
possibly cover the current specification, so we must change the
specification.  Given our track record at publishing new drafts, this
means that we wouldn't be final until _at least_ Q1 2008, if not Q2.


It is Very Bad if I believe #2 is probable.  Thus I would prefer to
believe it is _not_ possible, leaving me with only #1.  And #1 has no
negative consequences to calling the spec final _now_.

Am I mischaracterizing the situation here?

specs mailing list

Re: OpenID 2.0 finalization progress

2007-10-19 Thread Kevin Turner
On Fri, 2007-10-19 at 10:02 -0700, Paul C. Bryan wrote:
 On Thu, 2007-10-18 at 19:13 -0700, Dick Hardt wrote:
  I don't see why the two processes need to be any more dependant on  
  each other then they are already.
 With all due respect, why take the risk that there are intellectual
 property issues after the specification is finalized?

I'll let my ignorance show here: How will any potential IPR issues
affect the final specification?  I recognize that many parties require
the IPR documentation before moving forward with their adoption of
OpenID.  However, there are many parties who do _not_ feel that need,
and I do not understand what the downside is to calling the
specification final now.  Are we waiting on the results of a patent
search which might necessitate re-working parts of the protocol?  What
exactly are the consequences, worst case, in calling the specification
final before the IPR is sealed?

specs mailing list

Re: Please clarify 2.0 TOC 14 -- Re: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification

2007-05-22 Thread Kevin Turner
On Fri, 2007-05-18 at 22:21 +0200, Boris Erdmann wrote:
 Should the document be placed under or
 or does it have to be link rel'ed in every page?

For the proposed check against realm forgery, you'll want to make sure
it's available at the URL given in the openid.realm parameter of your
checkid request.  Josh is currently writing up the details on that.

For other uses, I think the answer is it depends; what are those uses?
Publishing it at return_to_url doesn't seem to be very useful, because
it's the return_to url that the seeker would be trying to discover.
That would be the equivalent of a sign saying you are here and nothing

specs mailing list

Re: Updated normalization section to match the upcoming XRI Syntax 2.1.

2007-04-04 Thread Kevin Turner
Sorry it took me a few months to notice this, but xri://$dns?  No.  I'm
referring here to spec rev 274, the diff for which is attached.  Can we
roll that patch back, please?

I'm not even sure where you're getting an XRI Syntax 2.1 reference from,
there's not so much as a working draft of it published on the technical
committee's page at OASIS.



Index: openid-authentication.xml
--- openid-authentication.xml	(revision 273)
+++ openid-authentication.xml	(revision 274)
@@ -745,17 +745,18 @@
   list style=numbers
-  If the user's input starts with the xri:// prefix,
-  it MUST be stripped off, so that XRIs are used in the
-  canonical form.
+  If the user's input starts with one of the xri://,
+  xri://$ip*, or xri://$dns* prefixes, they MUST be
+  stripped off, so that XRIs are used in the canonical
+  form, and URI-authority XRIs are further considered URL
+  identifiers.
   If the first character of the resulting string is an
-  XRI Global Context Symbol (=, @, +, $, !) or (,
-  as defined in Section 2.2.1 of
-  xref target=XRI Syntax 2.0 /, then the input SHOULD be
-  treated as an XRI.
+  XRI Global Context Symbol (=, @, +, $, !) as
+  defined in Section 2.2.1 ofxref target=XRI Syntax 2.0 /,
+  then the input SHOULD be treated as an XRI.
@@ -3016,16 +3017,20 @@
specs mailing list

Re: Re[2]: Identifier portability: the fundamental issue

2006-10-17 Thread Kevin Turner
On Tue, 2006-10-17 at 13:29 +1000, Chris Drake wrote:
 Now - how comfortable are you with
 the idea of letting 1.5 billion Chinese people use OpenID

Ideally we'd have the input of the SocialBrain Foundation on that.
Those are the folks who put together  Has anyone on this list
talked to them at all?

specs mailing list

Re: Adoption questions

2006-10-06 Thread Kevin Turner
On Fri, 2006-10-06 at 13:26 +1000, Chris Drake wrote:
 Is my understanding accurate: OpenID is unable to support single sign
 on.  If not - lets assume it's 9am.  I just signed on.  I can visit
 RP#1 then RP#2 then RP#3 and go back and forth all day without
 hindrance, until I next sign off - yes?

This depends almost entirely on the configuration of the RPs involved,
but I think the situation you describe is quite doable.

 Privacy: during any hypothetical overheard lunchtime conversation
 between The CEO of RP#1 and the CEO of RP#2 - nobody's ever going to
 hear this fragment of conversation: ... yeah - that troublemaker is
 one of our users too ... - or are they?

Being able to identify troublemakers across sites is one of the chief
features of a system like OpenID.  It's what enables reputation systems
and helps content providers break out of silos.  However, if as a user,
you don't like that feature, you can use directed identity with OpenID.

This requires using an IdP with enough other users to provide you with
some degree of anonymity -- if you run your own IdP, and are causing
enough trouble to draw attention to yourself, they're likely to figure
out that everyone using that IdP is you, no matter how many different
identifiers you have it assert.

Then you provide different identifiers to RP#1 and RP#2.  Under OpenID
1.x this is rather cumbersome to do without custom tools in the user
agent, but OpenID 2.0 enables IdP-driven identifier selection, which
means your IdP can help you keep track of which identifier you provide
to which RP.

Also keep in mind that, even in the absence of any global user
identifier scheme, the Internet presents other challenges to complete
anonymity, e.g. your IP address.  The level of technical understanding
and aptitude required to avoid detection by those basic means will
probably place it out of reach of most casual users.

and, as an aside, for a fun read about just what can be done with your
IP address in the hands of an outfit like the RIAA's legal team, see

specs mailing list

Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

2006-10-06 Thread Kevin Turner
(change #3):
 Impact on XRI-based auth:
 An XRI is, for this purpose, a URI that can be resolved into a URL at
 which we can do Yadis discovery. Once Yadis discovery begins, flow
 continues as in the original proposal, where openid:Token can be any

It's unclear to me whether you intended this to be a change from the
current specification or not, but it is.  Yadis discovery on URLs
resolved from XRIs is considered redundant, as there's nothing about
Yadis discovery that can't be done while resolving the XRI.  Since Yadis
uses the XRI resolution response format, you even get to use the same

So was it your intention to add an extra layer to discovery here, or
should the above section be reworded?

specs mailing list

RE: [PROPOSAL] bare response / bare request

2006-10-06 Thread Kevin Turner
On Fri, 2006-10-06 at 16:34 -0700, Drummond Reed wrote:
 Let me play the dumb customer here and say:
 * A whole lot of real-world users would love OpenID-enabled bookmarks. 
 * A whole lot of websites would love to offer them.
 * A whole lot of IdPs would love to provide them.

Okay Customer, if both websites and IdPs would love it, is it okay if
it's something that websites + IdPs can layer on top of the core?  If
some sites chose not to, and the IdP said login bookmark not available
for this site, would that be okay?

specs mailing list

RE: [PROPOSAL] authentication age

2006-10-02 Thread Kevin Turner
On Sun, 2006-10-01 at 13:08 -0700, Recordon, David wrote:

 It could be augmented to also contain a response parameter telling the
 RP if the IdP acknowledged it, then the RP could make the decision if
 it wants to proceed.

You will want that response parameter.  Otherwise, couldn't I (as the
attacker who has the user's IdP cookie) just drop the auth_age parameter
from the checkid request?

specs mailing list

featuritis for existing form handlers (was: Sorting fields in signature generation)

2006-09-27 Thread Kevin Turner
Re-writing all your applications every time a new technology pops up is
not a very efficient use of resources.  New technologies that can
leverage an existing install base will likely fare better than those
that demand a completely clean slate.  So I won't argue that existing
applications are never an important consideration.  However, I don't
believe the features you're proposing here (pass-through and
multi-valued parameters) are either beneficial to OpenID or necessary
for your OpenID application.

As far as I understand it, you want these features to use existing form
handlers.  These form handlers have not been written for OpenID.  As
such, they must not be checking the signature of the submitted data, not
confirming that it comes from it comes from the user's designated IdP.
You're going to have to write application-specific submission code for
each of them, as their parameter names follow no common standard.  Why,
then, should the OpenID specification describe their behavior?  Why
should the OpenID standard be required to include this set of very
un-standardized non-OpenID applications?

Your scenario does not sound like OpenID.  It sounds like something
called HTML form submission.  We needn't confuse the two.

These changes are not free.  If nothing else, they've cost you the time
it took to read this message.  They would require adding words to the
specification which will not reduce its complexity.  And the
multiple-value changes are not natural to implement in many of the
environments in which we need to see OpenID implemented.  Granted, that
may be because PHP has a cripplingly brain-dead method of argument
processing, but I see the options here as this:

1) Making a change for the benefit for certain legacy applications, but
one that will add complexity to all OpenID implementations in PHP,
Rails, and others.

2) keeping OpenID practical to implement in the most popular web
platforms, at the expense of some unknown set of applications which
don't intend to leverage OpenID's features anyway.

Barry objected when I said you're asking for this feature be made a
priority, but making a change to the specification that caters to these
applications at the expense of implementations in other widely-deployed
platforms is doing exactly that.

specs mailing list