Re: Auth 2.0 spec errata regarding delegation vs. directed identity

[Josh Hoyt]

On Wed, May 21, 2008 at 1:03 PM, John Ehn <[EMAIL PROTECTED]> wrote:
> I'm tending to agree with Martin on this one.  I guess that statement does,
> in a roundabout way, implies the Relying Party should do the following:

This is probably because I'm so familiar with the protocol and the
spec, but I'm not sure what exactly you're asking for. That section of
the spec lists the fields in the discovered information that must be
matched against the OpenID id_res response and what to match them
against. I don't see the ambiguity.

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

Re: Auth 2.0 spec errata regarding delegation vs. directed identity

[Josh Hoyt]

On Wed, May 14, 2008 at 11:20 AM, Martin Atkins <[EMAIL PROTECTED]> wrote:
>  * The RP, when verifying that the openid.claimed_id URL in the
> assertion is valid, checks only that the openid2.provider value is
> correct, and doesn't check that the openid2.local_id value matches
> (after removing the fragment part) the openid2.identity URL.
[...]
>
> Both of the above are currently allowed by the Auth 2.0 spec, but since
> doing the above checks doesn't seem to remove any useful possibilities,
> I think there ought to be some sort of errata that requires the checks
> I've listed above.

The "Verifying Discovered Information" section[1] of the OpenID 2.0
Authentication spec is actually pretty explicit about the fact that
the relying party needs to verify this: "If the Claimed Identifier is
included in the assertion, it MUST have been discovered by the Relying
Party and the information in the assertion MUST be present in the
discovered information." It then goes on to list the information that
must be verified.

I think this is already covered.

Josh

http://openid.net/specs/openid-authentication-2_0.html#verify_disco
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

OpenID Authentication 2.0 errata addition - unsupported association response code

[Josh Hoyt]

When handling a bug report[1] about our PHP library[2], we encountered
an ambiguity in the spec when dealing with associate requests for
unsupported types. I've added the resolution to the spec[3] errata
page[4] on the wiki. I don't think this is a very controversial
change, but let me know if this sounds wrong to anyone.

Josh

1. http://trac.openidenabled.com/trac/ticket/155
2. http://openidenabled.com/php-openid/
3. http://wiki.openid.net/Errata_-_OpenID_2.0_Authentication
4. http://openid.net/specs/openid-authentication-2_0.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Errata (was Re: openid:Delegate undefined namespace)

[Josh Hoyt]

We failed to update the spec to include the OpenID 1.1 XML namespace
for XRDS discovery. We should create an errata document for the OpenID
2.0 spec on openid.net and add this information.

On Dec 3, 2007 9:56 PM, Manger, James H <[EMAIL PROTECTED]> wrote:
> Section 14.2.1 "Relying Parties" (discussing compatibility with OpenID 1.1) 
> says:
>   "the end user's OP-Local Identifier appears in the  tag"
> However, the namespace URI associated with the "openid" namespace prefix is
> not defined.
> I guess it should be "http://openid.net/xmlns/1.0";, which needs to be
> mentioned in the spec.
>
> Change "" in the 2nd dot point in 14.2.1 to
> ""
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Adding fields to SREG (was: Re: SREG namespace URI rollback)

[Josh Hoyt]

On 11/1/07, David Recordon <[EMAIL PROTECTED]> wrote:
> Sorry it took me a few days, but seems alright to me.  I think a
> larger question would be if there should be any material differences
> with SREG 1.1 such as adding a few additional common fields.

-1 on adding anything to SREG; that's what Attribute Exchange is for.

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

Re: HMAC-256 vs HMAC-SHA256 for openid.assoc_type

[Josh Hoyt]

On 10/30/07, Manger, James H <[EMAIL PROTECTED]> wrote:
> It was "HMAC-SHA256" in draft 9 (10 Sep 2007), but had changed to "HMAC-256" 
> in draft 10 (13 Oct 2007). The change is looking more like a typo.

Indeed, this is an error in the text. It's intended to be HMAC-SHA256.

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

Re: OpenID 2.0 finalization progress

[Josh Hoyt]

On 10/22/07, Gabe Wachob <[EMAIL PROTECTED]> wrote:
> 3) the community calls the spec final and a contributor raises a potential
> patent infringement issue, and since the community has already implemented
> and deployed 2.0, the patent owner has more leverage because the costs of
> "engineering around" the claims in the patent have gone way up because of
> already-deployed software.

In order for this to be a concern, there needs to be a party who currently:
 1. has a patent that the spec infringes upon
 -- and --
 2. intends to claim infringement it if the spec is released without
an IPR agreement in place
 -- and --
 3. would be party to the IPR agreement

Did I get this right?

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

OpenID 2.0 finalization progress

[Josh Hoyt]

Hello fellow OpenID spec participants,

As I wrote in August [1], it's time to get the specification declared
final. We've had quite a while now for implementations and
specification feedback. Here at JanRain, we've implemented the draft
specification in Python [2] and PHP [3], and I know that the folks at
Sxip have implemented and deployed it in Java [4]. I know that at
least those implementations have beed tested against each other, and
worked successfully. I haven't heard of any new spec issues raised
from implementation.

As such, I am in favor of declaring Draft 12 the final draft and
blessing it as OpenID 2.0.

Do the other specification editors agree that now is the time to
declare OpenID 2.0 finished?

Josh Hoyt <[EMAIL PROTECTED]>
OpenID: http://j3h.us/

1. http://openid.net/pipermail/specs/2007-August/001953.html
2. http://openidenabled.com/python-openid/
3. http://openidenabled.com/php-openid/
4. http://code.google.com/p/openid4java/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Announce: OpenID Authentication Draft 12 (finally)

[Josh Hoyt]

Hello OpenID community,

I'm happy to announce draft 12 of the OpenID Authentication 2.0
specification [1]. It's been a long time [2] since the previous draft,
and it's past time that we get the work that has been done out, so
that users and developers can benefit from OpenID 2.0.

In the next month, we'd like to see implementers update their
libraries or applications to be draft 12 compliant and perform
interoperability testing. Once this period is over (October 1st), we
should call the specification final, pending final IPR clearance from
contributors. If we have IPR clearance by that point, we can call the
spec final on October 1st.

In the past, we've had timelines proposed and slipped. I don't think
there's any reason for that to happen in this case, and I hope that
the community will hold the editors accountable.

Let's get this done!

Josh Hoyt <[EMAIL PROTECTED]>
OpenID: http://j3h.us/



1. http://openid.net/specs/openid-authentication-2_0-12.html

2. http://openid.net/pipermail/specs/2007-January/001155.html

3. Major changes to the OpenID authentication specification, draft 11
to draft 12:

* Specify handling of URL fragments

* Realm verification using XRDS discovery

* Don't allow unencrypted secret exchange unless operating with
  transport layer encryption
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Identifier recycling write-up on the wiki

[Josh Hoyt]

On 6/20/07, Chris Drake <[EMAIL PROTECTED]> wrote:
> You've got 6 points under the "use cases", but it's really just 1 use
> case, and then 5 consequences [of] recycling.

I was trying to precisely define the identifier recycling problem to
which people are discussing a solution. Feel free to correct the
structure if you have a better presentation, or to add more depth to
the problem description.


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

There is certainly room for opposition, but I tried to frame this
issue with a minimum of bias, and I hope that anyone who contributes
to the wiki will try to do the same. That is, I encourage you to add
or correct anything that's there (it's a wiki, after all), but please
add a section "arguments against identifier recycling" or similar, so
that the whole context is preserved.


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

I think there is a big difference between giving someone an *identity*
and giving them an *identifier.* I know that LiveJournal recycles
names, and so do other large sites. I think it's more a matter of
whether we acknowledge that this is going to happen and try to come up
with something that will work for users and site operators or pretend
that it's not going to happen and deal with the consequences.

That said, I'm mostly trying to collect the whole community's
viewpoints into one document to aid in the decision process rather
than pushing a particular agenda.

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

Identifier recycling write-up on the wiki

[Josh Hoyt]

Hello,

I spent some time thinking over the issues and going over the
discussions that have happened about identifier recycling, and I wrote
up what I understand about the issue on the OpenID.net wiki [1]. I
think that my best contribution was to try to come up with as many use
cases as I could that related to identifier recycling. I'd love help
in fleshing out the use cases that I came up with, or additions of any
use cases that I missed.

I also wrote up what I knew about each of the proposals for
implementing identifier recycling on its own wiki page. Those pages
are linked from the page with the use cases [1]. I hope that these
documents can help us to reach a conclusion about identifier
recycling. I tried to keep commentary and bias to a minimum. (You get
enough of that from me here on the mailing list.)

I hope that by refining these proposals on the wiki and fleshing out
the use cases, we can understand the problem better and home in on the
solution that best solves the problem.

Josh

1. http://openid.net/wiki/index.php/Identifier_Recycling
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

[Josh Hoyt]

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?
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: The CanonicalID Approach

[Josh Hoyt]

On 6/9/07, Martin Atkins <[EMAIL PROTECTED]> wrote:
> I'm assuming that the RP authenticates
> http://inconvenient.example.com/001, not
> http://impersonation.example.com/mart. 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 http://impersonation.example.com/mart 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
identifier.

then two discovery steps are necessary in order to use this scheme.

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

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

[Josh Hoyt]

On 6/8/07, David Fuelling <[EMAIL PROTECTED]> wrote:
> If in 50 years, a given canonical URL domain goes away, then couldn't a
> given OpenId URL owner simply specify a new Canonical URL in his XRDS doc?

If I understand the way that David Recordon and Drummond are proposing
that canonical identifiers work, this is not the case. The canonical
identifier is the sole database key, and the URL that the user enters
and everyone sees is reassignable and (to a certain extent) ephemeral.
Control of the canonical identifier is necessary and sufficient to
assert one's identity.

If I understand Dick, he's proposing using multiple identifiers as a
kind of multi-factor authentication, where the user has to present
more than one credential in the form of identifiers to take an action.
This is very similar to your interpretation of two URLs being
necessary. It's an interesting idea, and it has a lot of nice
properties, but it seems like a pretty big leap at this point. I think
the biggest drawback is that the nice properties only really appear
when each identifier is issued by a separate authority.

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

Re: The CanonicalID Approach

[Josh Hoyt]

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 "http://mart-atkins.com/"; as your identifier,
with a canonical id of "http://inconvenient.example.com/001";

I can set up a URL "http://impersonation.example.com/mart"; that points
to an OpenID provider that I control, and give it the same canonical
ID, "http://inconvenient.example.com/001";.

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?

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

Re: The CanonicalID Approach

[Josh Hoyt]

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 "" 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.

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

Re: Questions about IIW Identifier Recycling Table

[Josh Hoyt]

On 6/8/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> The difference I see is that the current secrets can be renegotiated.
> If we're working with non-public fragments then they cannot be.  If
> we're working with public fragments, then I'm less concerned.

I understand your concern, but I don't share it. There will be times
that secrets are lost, but I think that the benefit of protecting
users from identifier loss is more important than the cost of
requiring a reliable provider.

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

Re: Questions about IIW Identifier Recycling Table

[Josh Hoyt]

On 6/7/07, David Fuelling <[EMAIL PROTECTED]> wrote:
> > I'm not sure I understand what's "public" about this. If I understand
> > it correctly, from the relying party's perspective, the user's account
> > is keyed off of the pair of the identifier and the token. This sounds
> > like URL + private token in that table. Am I missing something?
>
> Maybe I don't understand the difference between private and public tokens.
> My proposal used private information to create a public token that can be
> sent via AX (thus the hybrid term).  Am I understanding the difference
> between private/public tokens incorrectly?

I think I see how we're using the term differently. The token only
protects your identifier if the relying party does not ever display
it. If the relying party did display it, anyone who gained control of
your identifier in the future could just send that (reusable) token
along with an assertion in order to gain access to a relying
party. Since the relying party needs to keep the token secret, I was
calling it "private." It's shared between the provider, the user, and
the relying party, but it's secret from anyone else.

I think it's also important to note that the transport mechanism for
the token (using attribute exchange, as an extra field or as a
fragment) is independent from whether the token should be shared. I
think using attribute exchange for this core feature is a non-starter,
since it would create a dependency on the attribute exchange in the
authentication spec.


> > This approach was rejected at IIW because:
> >
> > 1. An extra database field is required (whether or not the data is
> > transmitted using attribute exchange)
>
> If the AX database schema is architected properly, then the addition of a
> new AX attribute should not necessitate a new database column.  If this were
> the case, then AX would not really be feasible (how would an RP deal with a
> new AX attribute?).

If you have an existing application and you are adding OpenID support,
in order to support the token, you would have to alter your
schema. When creating a new application, it's not a big deal. I also
expect that few relying parties will support *arbitrary* attributes,
since the relying party will not be asking for attributes that do not
have specialized uses anyway.

Perhaps this deserves clarification on the wiki page.


> > 2. There is no obvious way to tell if a user is the same user across
> > sites (The identifier contains a secret portion)
>
> Good point.  Although, let's assume that RP's display fragment-enabled
> OpenID's in the following manner, which overcomes the "Fragments are Ugly"
> problem:
> http://me.example.com#1234";>http://me.example.com
>
> Users will not be able to easily distinguish that the OpenID is owned by a
> different user without hovering over the URL in their browser.  That said,
> computers will be able to, since the actual HREF is what counts, I assume.
> Has this been discussed wrt to fragments.

There has been some discussion about it. It's a tough issue, and it's
one of the reasons that I asked the (surprisingly controversial)
question about whether we can just add the token to some part of the
URL, if it's going to be publicly available anyway. If it's a visible
part of the URL, both users and software agents will be able to tell
the difference between identifiers.

In the discussions that we have had about this issue so far, we have
concentrated on a user gaining access (either on purpose or
accidentally) to resources that were controlled by the previous owner
of their identifier. For example, a user could sign in to a photo
sharing site and see someone else's photos.

A  related  issue  is  that  of  a  third  party  mistaking  resources
controlled by the  previous owner of a URL as  being controlled by the
current owner. For example, a potential employer does a search for the
user's identifier  and finds photos of some  illegal activity, without
the uniquifying token as a visible part of the URL.



> > 3. Concern about depending on a secret for a user to be able to sign
> > in to a site (David's Wordpress issue)
>
> I think DR had a problem with anything that could be lost, thereby
> preventing access to an RP.  Both Fragments and Tokens seem to suffer from
> this problem, since in the Fragment scheme, if I or my OP forgets what my
> fragment was, I won't be able to login to an RP without recycling my account
> (or forcing an account recovery procedure).
>
> Seems like the odds of my OP losing my fragment information are pretty slim.
>  Identically, the odds of my OP losing my recycling_password are pretty
> slim, too.  What's more, If *I* lose my recycling password, why should I
> care?  Only the OP needs to deal with it, and perhaps the OP can just show
> me that password in an account settings page when I login(?)

If the token is publically viewable, then losing it is not an issue. I
do not share David's concern about depending on a secret, since both
the relying party a

Re: Questions about IIW Identifier Recycling Table

[Josh Hoyt]

On 6/7/07, David Fuelling <[EMAIL PROTECTED]> wrote:
> Over the last few days I've been thinking about your Identifier Recycling
> proposal[2], in addition to other proposals (Tokens, etc).  Assuming I
> understand things correctly, it seems as if a hybrid of the public/private
> token approach would seem to garner the most checks, per the IIW grid.  Not
> sure if my idea is technically correct or not, so please let me know if what
> I'm proposing falls short anywhere.  Here goes

I'm not sure I understand what's "public" about this. If I understand
it correctly, from the relying party's perspective, the user's account
is keyed off of the pair of the identifier and the token. This sounds
like URL + private token in that table. Am I missing something?

This approach was rejected at IIW because:

 1. An extra database field is required (whether or not the data is
transmitted using attribute exchange)

 2. There is no obvious way to tell if a user is the same user across
sites (The identifier contains a secret portion)

 3. Concern about depending on a secret for a user to be able to sign
in to a site (David's Wordpress issue)

I'm not sure which of these issues were the basis for rejecting this
approach. To me, the biggest problem with it is (2)

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

Re: The "WordPress" User Problem (WAS: RE: Specifying identifierrecycling)

[Josh Hoyt]

On 6/5/07, Drummond Reed <[EMAIL PROTECTED]> wrote:
> I supposed this doesn't apply to large sites, where all identifiers are
> managed "in trust" for users and they can enforce non-access to previous
> fragments. But for personal URLs it doesn't appear to work at all. Am I
> missing anything?

Enabling recycling for large sites that control their own identifiers
was the use case that was declared mandatory to cover for the OpenID
2.0 specification. I would personally like to have a solution that
protects identifiers without a central manager, but that is not the
case that is holding up OpenID 2.0.

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

Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)

[Josh Hoyt]

On 6/5/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> > The fragment is not secret. It is not "protecting" your OpenID. You
> > should be able to get the fragment from any relying party that you
> > visited.
>
> I believe David's point is that you cannot retrieve the fragment from
> the RP if you have lost it and are no longer able to log into any
> RPs. (Unless there's an account recovery mechanism either on the RP
> or the OP.) The RPs know it, but are not supposed to display /
> disclose it.

The relying parties SHOULD make the fragment available to software
agents, at least, so that it's possible to compare identifiers across
sites. If the fragment is never available, then there is confusion
about which user of an identifier is responsible for content that has
been posted. One use case where software agents having access to the
fragment is particularly important is if the identifier is used for
access control, and the access control list is retrieved from off-site
(e.g. from a social networking site).

The implementation that seems most sane is for places that display the
identifier for human reading look like:

 http://josh.example.com/#this-is-intended-for-machine-consumption";
  >http://josh.example.com/

so that the software agent would see the fragment, but the user
wouldn't have to.

Using this approach, the fragment is trivially available anywhere you signed in.

There is also no reason that a relying party should hide the fragment
if a user asks for it. Since it is not sensitive information, it does
not require "account recovery."

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

Re: The "WordPress" User Problem (WAS: RE: Specifying identifier recycling)

[Josh Hoyt]

On 6/5/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> Imagine if I install WordPress (or insert other app here) on
> https://davidrecordon.com and check the "Use fragments to protect my
> OpenID" box.  A few months later I decide to remove WordPress, or an
> upgrade blows away my OpenID extension data, or I'm using an extension
> which stores the fragments in /tmp/ and they get blown away.  I now no
> longer have access to my accounts on all the relying parties I've
> visited.  Now what do I do?

The fragment is not secret. It is not "protecting" your OpenID. You
should be able to get the fragment from any relying party that you
visited. You might choose to use a fragment if you have acquired a
recycled identifier, but you can choose the fragment. It protects
*nothing* if you control the base identifier (to the point that you
can choose an OpenID provider).

I'm not arguing for or against a particular approach here, but I think
your argument is flawed.

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

Re: Auth 2.0 Extensions: Namespace Prefixes

[Josh Hoyt]

On 6/5/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> Since it seems no one has replied yet, I'd agree that this would make
> implementations easier.  Iterating via a regular expression seems ugly
> and hard to do (well except in Perl). :-\

-1. It's one more thing to get wrong. There would then be the case
where an extension had a namespace alias declaration but was missing
from that list, or was in that list but did not have a namespace alias
declaration.

Iterating one time to build a lookup table is easy, and you get the
namespace URIs out of that one iteration.  It doesn't take regular
expressions (it's just a prefix match), and I've never used a language
that would make this kind of iteration difficult.

Each technique implemented in Python for comparison:

prefix = "openid.ns."
prefix_len = len(prefix)

def extractNamespaceAliases(query):
"""Extract the namespace URIs from a dictionary containing a
parsed HTTP query string or POST body. Returns a dictionary from
namespace alias to namespace URI.

This code implements the current draft of the OpenID 2.0
specification. Very straightforward.

"""
namespace_aliases = {}

for k, v in query.iteritems():
if k.startswith(prefix):
alias = key[prefix_len:]
namespace_aliases[alias] = v

return namespace_aliases

def extractNamespaceAliases1(query):
"""Extract the namespace URIs from a dictionary containing a
parsed HTTP query string or POST body. Returns a dictionary from
namespace alias to namespace URI.

This version implements the proposal in this thread. The code has
more branches and has to build new strings as lookup keys.
"""
namespace_aliases = {}

namespace_string = query.get('openid.extensions')

# Ignore missing or empty "openid.extensions" parameter
if namespace_string:
aliases = namespace_string.split(',')

for alias in aliases:
try:
namespace_aliases[alias] = query[prefix + alias]
except KeyError:
pass # Ignore declared but missing extensions

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

Specifying identifier recycling

[Josh Hoyt]

Hello,

I started writing up the use of fragment identifiers for URL-recycling
for the OpenID 2.0 authentication spec, and I ran into some unforseen
challenges. It's not obvious how a relying party should behave when a
URL with a fragment is entered. How should the discovery process work?
How should fragments work with delegation (both as the claimed
identifier and the provider-local identifier)?

After thinking this over for a while, I'm no longer convinced that
using URI fragments as the uniquifying value is the right
approach. Looking at the available options, I think that the best
approach might be to add a uniquifying value to some part of the URL,
in a provider-specific manner. For instance:

  I own . I delete my account, and so it
  goes back in the pool of identifers. The next Josh who registers the
  username "josh" at MyOpenID.com gets .

Providers can also provide a redirect from the general form of the
identifier to the current version of the identifier so that users do
not need to remember or type the uniquified version. This is pretty
much equivalent to the fragment scheme, except:

  * It does not require spec changes (and is backwards-compatible!)

  * The uniquifying component is user-visible

I'd like to hear opinions on whether this unique-URL solution is good
enough to solve the problem. If you think it isn't, I'd like
suggestions on how discovery and delegation should interact with
fragments.

Josh


For reference, here's a comparison of the three different approaches
to solving the identifier recycling problem:

1. Using a URI fragment with a uniquifying value:

  * No database changes necessary on the RP (the RP can store the URL
with the fragment as the identifier)

  * Potential problems with initiation and discovery

  * Potential problems with inconsistent behaviours on OpenID 1 sites

  * Comparing identifiers is easy

  * URLs that user see may be ugly or inconsistent across sites (if
some relying parties do and others do not strip the fragment
before display)

  * There is no difference between different versions of a
*user-displayed* identifier (users can't tell if a reference to a
URL in the wild belongs to the current ownder of a URL or another
user).


2. Adding an extra field with a uniquifying value:

  * Database change required

  * No change in initiation or discovery

  * OpenID 1 sites will behave as they do now

  * Identifier comparison is no longer obvious

  * Display URLs are easy

  * There is no difference between different versions of an identifier


3. Just use different URLs:

  * No database change required

  * No change in initiation or discovery

  * No implementation change at all (just a new best practice)

  * Comparing identifiers is easy

  * Display URLs are easy

  * Users can tell the difference between an old and a new identifier
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Realm spoofing spec patch

[Josh Hoyt]

Allen,

On 5/29/07, Allen Tom <[EMAIL PROTECTED]> wrote:
> From an implementation perspective, it might make sense for the OP to
> verify the RP during the association request, so that the association
> handle is only returned after the RP has been verified.

Were you concerned about implementation complexity or the time it
could take to do discovery while the user is waiting?

At association time, the provider does not know who the relying party
is. Are you proposing that the realm be included in the association
request? In that case we'd have to include the discovery URL, in the
case of a wildcard realm.

I see two potential problems:

 1. If the discovery happens during the association request, a
single-threaded relying party might not respond to the
verification request. This wouldn't come up too frequently in
production, but it would raise the bar for example and prototype
code.

 2. If the form of a return_to URL changes (and the relying party
updates the discovery information to match) it would be good if
the provider could attempt verification again, so that a valid
request could complete successfully.

(2) requires the same flow as the proposed implementation
(verification during the course of the request), and so I think it's
simpler to just leave it in-band. I suppose that the specification
could remain silent on *when* to perform the verification, since it
doesn't really matter from a security perspective, which would leave
both channels open, as long as the pertinent information was added to
the association request.

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

Realm spoofing spec patch

[Josh Hoyt]

Hello,

I've added a section to the specification[1] about performing
verification on the realm to avoid realm spoofing. In short, realm
spoofing is the problem of exploiting a bug on a site that a user
would trust to trick them into sending their information to a site
that they would not trust. This is very similar to many phishing
attacks. The difference between this type of attack and a standard
phishing attack is that the user will (usually) only see the realm,
and the realm may actually be trusted, so even an educated user who's
paying attention may be vulnerable.

There are also (minor) changes to the section on discovering relying
parties[2].

The fix that is described is for the relying party to provide a
whitelist of URL patterns that should be usable as return_to
URLs. Relying parties should be as restrictive as possible when
specifying return_to URLs.

This is the fix that was discussed at the Internet Identity Workshop,
by all of the spec editors and several prominent members of the OpenID
community. Please review the additions. If you'd like to see the
specific changes, you can look at the diffs in revision control[3].

Josh


1. 

2. 

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

Re: clarifying section 11.2 in draft 11 for HTML discovery?

[Josh Hoyt]

On 5/24/07, Peter Watkins <[EMAIL PROTECTED]> wrote:
> Shouldn't the spec clarify what is required for an HTML discovery to
> uphold an assertion that triggers 11.2's discovery process?

The spec as it is currently written does not support using identifier
selection with HTML discovery. That was intentional, to keep things
simpler. A user should never have to add markup to trigger identifier
selection. That is the responsibility of the OpenID provider.

I don't think we need to add a way to trigger identifier selection
with HTML discovery.

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

Re: HTML discovery: SGML entities and charsets

[Josh Hoyt]

Claus,

On 5/20/07, Claus Färber <[EMAIL PROTECTED]> wrote:
> Peter Watkins schrieb:
> > 7.3.3 in draft 11 says
> >
> > The "openid2.provider" and "openid2.local_id" URLs MUST NOT include 
> > entities other than "&", "<", ">", and """. 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,. .).
>
> Please note that the draft is completely broken here:

Can you suggest improvements and examples or test cases of how you
think it should work?

There has been a little discussion in the past about the restriction
on allowed character entity references. I don't think there has been
any about numeric character references, except in lumping them in with
character entity references.

These restrictions live on from the OpenID 1 specification, and were
preserved primarily to ease backwards compatibility (IIRC).

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

Re: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification

[Josh Hoyt]

Don,

On 5/18/07, Don MacAskill <[EMAIL PROTECTED]> wrote:
> My company, SmugMug, is an OpenID provider for hundreds of thousands of
> "high value" paying accounts, and will shortly be a consumer as well.
> I'll freely admit that I haven't fully digested 2.0's pre-spec, but at
> least part of that reason is it looks like it adds a lot more
> complexity.  I can honestly say that if I had seen it as a spec, rather
> than 1.1, I would have certainly put off implementation, possibly
> indefinitely.

As I have said a few times, the OpenID 2.0 specification is
significantly longer than the OpenID 1.1 specification, but most of
the length comes from being explicit and rigorous about things that
the OpenID 1.1 specification is not.

I welcome specific suggestions for simplifying or otherwise improving
the specification. The more feedback that we get, the better.

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

Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification

[Josh Hoyt]

On 5/18/07, Dmitry Shechtman <[EMAIL PROTECTED]> wrote:
> > I'm sure that this will break a few implementations
>
> It certainly will break PHP-OpenID.

Which implementation are you referring to as "PHP-OpenID"?

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

Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification

[Josh Hoyt]

On 5/18/07, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
> On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote:
> In order to be backwards compatible the HTML page should have two
> sets of tags one for OpenID 1.1 and one for OpenID 2.0, both pointing
> to the same OP endpoint URL. Otherwise an OpenID 1.1 RP will not be
> able to use the HTML page.

Also note that it's allowed to put both values in the "rel" attribute
of one tag [1], which eliminates a little bit of bloat.

Josh

1. http://www.w3.org/TR/html401/struct/links.html#adef-rel
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Proposal for improved security of association establishment in OpenID 2.0

[Josh Hoyt]

Guoping,

I'm not an expert, but I do understand the attack that you're
describing. I'm hesitant to make the change without input from Paul
Crowley, who designed the key exchange mechanism in the first place. I
hope that he will comment.

It should be noted that a man-in-the-middle can still be a problem if
they intercept (proxy) every message, and not just the
association-related messages. This raises the bar for being a
man-in-the-middle, but it does not eliminate the problem.

Josh

On 5/17/07, Guoping Liu <[EMAIL PROTECTED]> wrote:
> Issue: Vulnerability to man-in-the-middle attacks
>
> The association algorithm with DH-SHA1 and DH-SHA256 defined in the
> draft 11 is vulnerable to man-in-the-middle attacks if server
> authentication with HTTPS is not used. Here is how:
>
> A RP sends an associate request an OP with following parameters:
>
> openid.dh_modulus = base64(btwoc(p))
> openid.dh_gen = base64(btwoc(g))
> openid.dh_consumer_public = base64(btwoc(g ^ xa mod p))
>
> A middle man M intercepts the request. M then generates xc, creates a
> new request to the OP with following parameters:
>
> openid.dh_modulus = base64(btwoc(p))
> openid.dh_gen = base64(btwoc(g))
> openid.dh_consumer_public = base64(btwoc(g ^ xc mod p))
>
> The OP receives the request from M and sends following response to M
>
> dh_server_public = base64(btwoc(g ^ xb mod p))
> enc_mac_key = base64(H(btwoc(g ^ (xc * xb) mod p)) XOR MAC_key)
>
> M decrypts the MAC_key as follows:
>
> MAC_key = H(btwoc(g ^ (xc * xb) mod p)) XOR enc_mac_key
>
> M then sends a response to the RP with following parameters:
>
> dh_server_public = base64(btwoc(g ^ xc mod p))
> enc_mac_key = base64(H(btwoc(g ^ (xc * xa) mod p)) XOR MAC_key)
>
> Now, the RP, middle man M and OP all have the same MAC_key.
>
>
> Proposed Solution:
>
> Do not send enc_mac_key in response. Both OP and RP generate a MAC key
> as follows
>
> H(btwoc(g ^ (xa * xb) mod p))
>
> We are NOT sending the MAC key over and are not vulnerable to man in the
> middle attacks.
>
> Guoping Liu
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification

[Josh Hoyt]

On 5/17/07, Alaric Dailey <[EMAIL PROTECTED]> wrote:
> I hate to be a PITA but these issues were brought up a while ago by Eddy
> Nigg and Myself.

I understand, but at that time, as now, I was trying to get the spec
to be finished. We've been in something of an informal feature-freeze
for a while. Perhaps we should have explicit feature-freezes.

I'd suggest starting an OpenID 3 thread to talk about the features
that you want to add. That way, you can start trying to convince
people that your features should go in without having to battle with
people like me who just want to have a stable spec release with the
improvements that we already have.

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

Re: Final outstanding issues with the OpenID 2.0 Authenticationspecification

[Josh Hoyt]

On 5/17/07, Alaric Dailey <[EMAIL PROTECTED]> wrote:
>  There are 2 issues that I would like to see addressed.
>
> 1. Forcing Encryption, to protect users data en-route.
> 2. Validated assertions, validating certain bits of data with a third party.
>
> I know both of these have come up before, but have met with resistence, I
> would submit that with Sun and AOL supporting OpenID that these issues
> become more important, especially protecting the users data.

There are valid use cases for both of these features, but I think that
they can be addressed in a future release of OpenID. I want to get the
features that are already implemented out to users. Part of what will
be nice about getting 2.0 out is that it will give us more freedom to
start playing with new ideas.

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

Re: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification

[Josh Hoyt]

On 5/17/07, Dmitry Shechtman <[EMAIL PROTECTED]> wrote:
> > There is a proposed solution that we had consensus on (Dick's
> > "fragment" proposal.)
>
> Would you please specify whom you are referring to by "we"? I understand
> that various matters are being discussed outside of this list, but shouldn't
> the whole community be part of the decisions made?

Quoting myself:
> At the Internet Identity Workshop for the past few days, I've been
> talking to the people from the OpenID community about what is
> getting in the way of calling the spec final. I'm sending this
> message to summarize what I've heard, get comments from those of you
> who aren't here at this conference, and hopefully establish a
> concrete plan of action that will get the spec finalized.

That's the we and the consensus. This thread is explicitly about
getting those of you who were not there in on the decisions.

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

Re: RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification

[Josh Hoyt]

On 5/17/07, Dmitry Shechtman <[EMAIL PROTECTED]> wrote:
> "aside from XRI and Yadis"? XRI alone is twice as complex as OpenID 1.1!
>
> There has been a simplification suggestion floating around since long ago:
> resolve i-names via http[s]://xri.net/.

-1. If XRI is to be included, it should be done the way that it's
intended. One possible solution that would address this problem as
well as the unfinished XRI specification is to split out Yadis and XRI
discovery out from the OpenID Authentication spec and into separate
documents. That way, they could wait until the XRI specs are done and
the OpenID spec will be shorter and easier to understand.

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

Re: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification

[Josh Hoyt]

On 5/17/07, Sam Alexander <[EMAIL PROTECTED]> wrote:
> >  1. Identifier recycling. There are two different use cases for
> > identifier recycling. The first, and the one that most people who
> > I have talked to really want to solve is that of a large provider
> > that wants to allow re-use of parts of its namespace. The second
> > is if a user wants to relinquish control of an identifier without
> > relinquishing control of the places that they have used this
> > identifier. A concrete example of this is if I ever choose to stop
> > paying for j3h.us.
>
> This problem has already existed in the realm of e-mail for years
> (which I think is a great precedent for the problems we will (and do)
> face with OpenID).  OpenID does an even better job of mitigating it
> because of built-in delegation.  I think this should be left up to
> the OP to iron out (at least for now), and shouldn't be considered a
> block for finalizing the OpenID 2.0.

There is a proposed solution that we had consensus on (Dick's
"fragment" proposal.) This issue is a road block for certain companies
who have a large existing user base. I think that if we can solve it
without too much complexity and without taking too much time, we
should.

> >  2. Realm spoofing. This encompasses the attacks that Allen Tom has
> > described (using redirectors, proxies or XSS attacks) that create
> > new phishing opportunities and make certain types of phishing even
> > worse.
>
> There are solutions popping up like Verisign's plugin and our
> myVidoop implementation that are taking shots at how to battle
> phishing.

This is a totally different kind of phishing/proxy attack. This is not
an attack against the provider. Whether an authentication technology
is phishable is irrelevant to realm spoofing. Essentially, realm
spoofing uses holes in *relying party* sites to make users send data
to attackers. Read Allen Tom's messages that describe the problem for
more specific information about it.

As with the recycling issue, there are a couple of relatively simple
suggestions that make this problem a lot less severe. It's also a
pre-requisite for getting larger companies to adopt OpenID, so I think
it's worth addressing.

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

Re: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification

[Josh Hoyt]

On 5/17/07, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> 5. The OpenID Auth 2.0 spec is far more complex than the 1.1 spec,
> without delivering a corresponding amount of value for the
> complexity. There is a stronger form of the complaint, which is: even
> if did deliver a corresponding amount of additional value that
> corresponds to the additional complexity, wasn't the whole point of
> OpenID to be simple, and we should leave it at that level of simplicity?

I think this argument is bogus. There is hardly any additional
complexity aside from XRI and Yadis. I'm willing to entertain
suggestions for simplifying the handling of those discovery
mechanisms. The specification is significantly *longer*, but that's
primarily because it's much more rigorously specified. If you want it
simplified, don't just talk abstractly about complexity, make
suggestions about how to simplify it.

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

RFC: Final outstanding issues with the OpenID 2.0 Authentication specification

[Josh Hoyt]

OpenID 2.0 has been a work in progress for a long time. The
specification has been largely at a stand-still for long enough for
people to implement it, and even deploy it. At the Internet Identity
Workshop for the past few days, I've been talking to the people from
the OpenID community about what is getting in the way of calling the
spec final. I'm sending this message to summarize what I've heard, get
comments from those of you who aren't here at this conference, and
hopefully establish a concrete plan of action that will get the spec
finalized.

In the conversations that I've had, there are four issues that are
holding up people's approval of the specification. These issues are
not new, but I'm going to list them here:

 1. Identifier recycling. There are two different use cases for
identifier recycling. The first, and the one that most people who
I have talked to really want to solve is that of a large provider
that wants to allow re-use of parts of its namespace. The second
is if a user wants to relinquish control of an identifier without
relinquishing control of the places that they have used this
identifier. A concrete example of this is if I ever choose to stop
paying for j3h.us.

 2. Realm spoofing. This encompasses the attacks that Allen Tom has
described (using redirectors, proxies or XSS attacks) that create
new phishing opportunities and make certain types of phishing even
worse.

 3. Associations in the clear. While the OpenID 2 specification
specifically allows a provider to refuse to perform associations
in the clear (no Diffie-Hellman or SSL), there is consensus that
the specification should disallow these associations. This one's
easy.

 4. Reference to unfinished XRI specification. For resolving XRI and
the protocol formerly known as Yadis (XRDS discovery for URLs),
we're referring to a working draft specification. We can't leave
the final spec referring to the draft.

If these four issues are resolved, can we call the OpenID 2.0
Authentication specification done? Speak up if you have any other
show-stoppers.

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

Re: encoding newlines in attribute values

[Josh Hoyt]

On 4/19/07, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
> I think we do need pre-URL-encoding, mainly because of signatures. In
> order to calculate the signature the parameters must be put together
> in a special way and new line characters are not allowed.

Yes. The key-value encoding that's used for POST responses (to
associate and check_authentication) is also used in signature
generation. This is the source of the restriction on newlines in
values, not anything to do with URL encoding.

Each attribute already has to define its encoding rules and data-type.
The mechanism for encoding a newline can be part of this encoding, if
newlines are allowed in the value. Once there is one attribute that
has a defined encoding for newline, when new attributes are defined,
they can re-use this encoding. Does that sound reasonable?

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

Re: PROPOSAL schema.openid.net for AX (and other extensions)

[Josh Hoyt]

On 4/10/07, Rowan Kerr <[EMAIL PROTECTED]> wrote:
> Since
> the main difference I'm seeing at the moment is that SREG doesn't
> specifically request each value it wants, except in openid.sreg.required
> and openid.sreg.optional.

Um, that is exactly how sreg requests each value that it wants. If
it's in either of those lists, it's requested.

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

Re: Label replacing Key

[Josh Hoyt]

On 4/7/07, Douglas Otis <[EMAIL PROTECTED]> wrote:
> This would then require all locations that use the term "key" when
> referring to a field label to be changed to "label"

-1

If it needs to be changed, Martin's suggestion of "name" instead is much better.

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

Re: Logout

[Josh Hoyt]

On 4/6/07, Praveen Alavilli <[EMAIL PROTECTED]> wrote:
> I could only go only till Aug 2006 on the mail archives here:
> http://openid.net/pipermail/specs/ and nothing found specifically on
> "logout' (atleast based on the thread subjects).

I'd also search the other mailing lists, because the discussions on
each of them tend to blur together (spec issues on general, and so
on). I'll have to remember to bring the search issue up the next time
someone suggests Yet Another Mailing List.

> Any one know how and where we could get older archives ?

http://lists.danga.com/pipermail/yadis/

Can we get a copy of these archives on openid.net?

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

Re: Attribute Exchange 1.0 svn revision 295 review

[Josh Hoyt]

On 4/6/07, Dick Hardt <[EMAIL PROTECTED]> wrote:
> I agreed with you previously that the response being able to work
> either way if the request can. Sorry if that was not clear.

Great. That will simplify the code.

Given this change, is there still the need to have the special case
for sending an empty string as a null value? That case can be covered
(explicitly) by using count=0, even if omitting a requested value is
still illegal (see below).

> > Another restriction on the response message is that you have to send
> > responses even if they are empty. Can you give the rationale for
> > requiring the fields with no values to be sent?
>
> I am unclear on what your question is. Would you clarify?

Section 5.2 states:

"A response parameter MUST be sent for each requested attribute alias."

"This enables the RP to know that the OP did process the request."

Does it that the relying party will know that each requested attribute
was processed, or the request as a whole? And what would the relying
party be able to do if it got a response that indicated that the OP
had not processed the request? (send a bug report?)

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

Re: Logout

[Josh Hoyt]

On 4/6/07, Praveen Alavilli <[EMAIL PROTECTED]> wrote:
> well with OpenID atleast, I think we can easily design a logout
> extension, [...]
> Any reason why something like this was not incorporated into the specs yet ?

There is not general agreement on how this feature should be
implemented, or even exactly how it should work. Anyone care to search
back through the list archives and dig up the many previous
discussions of this topic? It'd be useful to the discussion to gather
the previous discussions together and make a wiki page about sign-out
with links to the previous discussions and a summary of the issues and
possible solutions to those issues (rather than a proposal).

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

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

[Josh Hoyt]

On 4/6/07, Dick Hardt <[EMAIL PROTECTED]> wrote:
> On 5-Apr-07, at 9:18 AM, Recordon, David wrote:
> > I'm fine with doing things differently, I'm not arguing that a
> > metadata
> > format should not be created, just that IMHO for simplicity sake of
> > reading the AX documents this format description should be merged into
> > the core protocol spec.  If down the road it should be split out
> > then it
> > always can be.
>
> Well, as one of the people that wrote the documents. We decided that
> having separate documents was better. Thanks for sharing your
> opinion. I have a different opinion.

Having started an implementation, I'm glad that metadata is not part
of the core, because metadata is not necessary for a wide range of
applications. I think it will be useful eventually, but I'm glad that
I can implement the core completely without thinking about metadata.
If metadata were part of the core (even optionally!) I might not have
even started writing code.

I do wish that this thread did not contain so much bickering.

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

Re: Attribute Exchange 1.0 svn revision 295 review

[Josh Hoyt]

On Apr 5, 2007 at 8:41 AM, Dick Hardt <[EMAIL PROTECTED]> wrote:
> > There is no way to say "I want as many of X as you have, and I don't
> > care how many that is"
>
> Good point. Perhaps have  a magic value like -1 to indicate as many
> as the user will release?
> I had thought the RP would likely have a maximum they would want in
> most situations.

Generally, yes, although when we were discussing the spec, we talked
about using one pass of attribute exchange to get all of the available
attributes and another pass to request the attributes themselves. When
requesting the available attributes, it seems like you'd want to say
"give me all the attributes that are available" instead of "give me up
to 500 available attributes," but I could be wrong.

It might be good to give a bound on the response size for every
request, although in cases such as above, it might be useful to the
relying party to know if there were values that overflowed the limit.
It wouldn't be difficult to add a flag, but I'm also not sure whether
it would be worth the extra complexity.



> > There is the issue that I brought up in a separate message where
> > count=1 is different from not specifying a count, even though they
> > both mean 1 or 0 values.
>
> The perl way would be to have "more then one way to do it" and allow
> both methods to mean the same thing.
>
> The python way would be "there is one way to do it" and not allow
> count=1 in a request

Well, clearly it's better to have one way to do it. But seriously, the
main problem that I have with it is that the specification prescribes
the response format based on the request format. That is, my code has
to keep track of whether the request used count=1 or just didn't
specify a count, instead of just recording that the request asked for
one value, so that the later code can know how to encode the value. If
there's really more than one way to do it, you should be allowed to do
it either way.

I'm guessing that you made that restriction on the response format so
that relying parties can know what the form of the response will be.
Is that correct?


Another restriction on the response message is that you have to send
responses even if they are empty. Can you give the rationale for
requiring the fields with no values to be sent?


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

Attribute Exchange 1.0 svn revision 295 review

[Josh Hoyt]

List,

I sat down with a couple other JanRain engineers and we took a look at
the Attribute Exchange draft and recorded some issues that we have.
There are probably other smaller issues, but this is what we came up
with in a quick (?) review.

Is editing of this spec by authors of other OpenID specifications
welcome? (I hope that by this review and my past spec work I'm showing
that I have adequate understanding and appropriate goals.)

Josh

Attribute Exchange specification v1.0 svn revision 295 review
***

Update URL issues
=

I assume that the update_url is intended to match the realm of the
authentication request. The spec doesn't say this anywhere.

There is no information about what form an update request will take,
or what a response to an update request will look like. Is an update
request supposed to be an OpenID authentication mode=id_res message?
If so, I think this is at least a little confusing, since the
user-agent of this HTTP transaction is not the user's browser, but the
provider's.

There doesn't seem to be a way to expire an update URL or unsubscribe
from updates.

There is no discussion of how an OpenID provider should behave if an
update URL does not respond (retry? stop using that URL? some of
each?)

Store Requests
==

The realm in a store request is somewhat meaningless; The provider has
no way of knowing whether the data came from something that's in that
realm, even if a return_to URL is provided.

What will happen to the data when a store is requested is not
discussed (will it replace the current value? will it get
concatenated? Does it depend on the attribute? If it's left up to the
provider, how will an RP know when it should initiate a store?)

Multiple Values
===

There is no way to say "I want as many of X as you have, and I don't
care how many that is"

There is the issue that I brought up in a separate message where
count=1 is different from not specifying a count, even though they
both mean 1 or 0 values.

The spec wording is unclear on what the count response parameter
should be. The example shows sending back a different count, which
suggests that the response count can be less than the request count,
but that should be explicit.

Could we do away with unspecified count in the interests of simpler
code everywhere? That way, we always know there's a count and the data
is always accessed in the same way.

It's not clear from the specification whether zero-length strings as
values for things with a count should be treated the same as they are
for things without a count.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Attribute Exchange pre-draft 5

[Josh Hoyt]

On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> Since draft_4 [1] we've done some implementation and testing (as well
> as listened to community's suggestions on related issues), and have
> incorporated some changes into a pre-draft-5. Before publishing it I
> would like to see your comments about them or about other features /
> changes that would be useful in AX.

If I understand correctly, the response to a request for an attribute
with "count.x=1" is different from the response for a request with no
count specified, even though the meaning is the same.

(namespacing left off for clarity)

Request:

 .type.a=http://example.com/a
 .count.a=1
 .type.b=http://example.com/b

Response:

 .type.a=http://example.com/a
 .count.a=1
 .value.a.1=avalue
 .type.b=http://example.com/b
 .value.b=bvalue

Even though the request for a and b have equivalent meaning (send zero
or one values for this attribute) the response MUST encode them in
different ways. I think this is ugly, because the detail of the way
that the attribute was requested has to be preserved in the code, to
ensure that the response can be encoded correctly. (it's not
sufficient to just default the count to one if it's not specified)

Is there a reason that it's specified this way? I'd prefer if there
was only one way to do it.

Also, can the count be zero in the response? it seems like that's OK,
and if it is, it'd address my concern about overloading zero-length
strings to mean "no value."

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

Re: SREG namespace URI rollback

[Josh Hoyt]

On 4/2/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> Sure, though I think there has also been a desire to do a bit of an
> actual rev to SREG to be more of a 1.1 version in terms of either
> explicitly supporting additional fields (such as avatar)  or allowing
> field names to be URIs themselves versus a hard-coded list of
> properties.

-1

SREG works because it's so dead simple. Attribute exchange is not much
more complicated, and it lets you specifiy field names with URIs *and*
allows you to define any attributes you see fit.

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

Re: SREG namespace URI rollback

[Josh Hoyt]

On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> But they are not the same -- the namespace alias can be different
> than "sreg". Are you suggesting that SREG1.1 must always use the
> "sreg" namespace alias?

They *are* the same protocol, going over different transports (that
is, embedded in different OpenID message formats). If you are sending
an OpenID 1 message, you *cannot* assume that the recipient will
support namespace aliases. If you're sending an OpenID 2 message, you
*cannot* assume that the recipient will support aliases without
defined namespaces.

I think it would be reasonable to always use "sreg", if for no other
reason than for clarity, but re-using the Type URI as the namespace
alias instead of creating a new one does not imply that the alias must
be "sreg" when using OpenID 2.

What if I put my proposal this way:

If Simple Registration is used with OpenID 1, the arguments MUST be
prefixed with "openid.sreg." If Simple Registration is used with
OpenID 2, the arguments MUST be in the namespace
"http://openid.net/sreg/1.0";

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

Re: Attribute Exchange pre-draft 5

[Josh Hoyt]

On 4/2/07, Rowan Kerr <[EMAIL PROTECTED]> wrote:
> On 2-Apr-07, at 3:14 PM, Josh Hoyt wrote:
> > My intuition is that a server could advertise what attributes it
> > supports rather than including this information in a user-specific
> > response. So, -0.5 on this. If it does go in, I'd say -1 on making it
> > REQUIRED.
>
> I suppose that (one or more) RDF file(s) could be returned as part
> of the AX discovery.. and the RDF's would have the attributes
> that are supported by the OP.
>
> I was just concerned about prompting a user multiple times
> for the same data, but if an RP can discover the supported
> attributes before requesting them, then that should cover it.

Why would the user be prompted more than once? I see it like this:

 RP: I want attributes A, B, and C.
 OP: OK, I support A, and B, and the user wants to send A, so my
response will contain A, but not B or C
 RP: OK, now I have A. I'll have to prompt the user for B and C if I
require them.

Is it prompting for B again that you're worried about?

If so, and it's required for the RP to do its job, then I don't think
that it's avoidable. If the user didn't want to send it, and it's
required, the application will have to stop the user one way or
another, and offering the user *some* way to continue is reasonable.

I think that the "required" request parameter will take care of most
of the problem, because users will know that if they refuse to send a
value for that attribute, the relying party will have to ask them.

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

Re: Attribute Exchange pre-draft 5

[Josh Hoyt]

On 4/2/07, Rowan Kerr <[EMAIL PROTECTED]> wrote:
> On 2-Apr-07, at 3:16 PM, Josh Hoyt wrote:
> > What about attributes whose value could reasonably be an empty string?
> > It would be reasonable to answer "don't do that," I'm just curious how
> > you expect this case to be handled.
>
> I'd say it's up to the RP to decide whether the data returned is
> valid for it's specific needs.

I'm thinking about differentiating between an attribute that's not
available and an attribute that *is* available, but its value is "".
I. e. difference between a null pointer, and a pointer to an empty
string.

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

Re: SREG namespace URI rollback

[Josh Hoyt]

On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> Sorry - I may be missing something, but I still say the problem
> remains: if a SREG1.1 party builds a message with a namespace alias
> different than "sreg", it can confuse the other party which may be
> expecting specifically "sreg".
>
> Or, put it differently, identifying SREG1.1 with the same URI as
> SREG1.0 would require all RPs and OPs out there to add the namespace
> alias param to their messages, since it is required in OpenID2/
> SREG1.1 (and that's what the URI also means).

OpenID 2 messages would use the namespace URI and OpenID 1 messages
would use the "sreg" prefix. If you do both, all the time, you don't
have to care which kind of message it is, but I'm not proposing that
we require doing that.

If you are making a SREG request, you won't have to care whether it's
supposed to be 1.0 or 1.1 because they're *the same*. You only have to
care whether it's an OpenID 1 or OpenID 2 request so that you can make
sure that the other end understands the namespacing.

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

Re: SREG namespace URI rollback

[Josh Hoyt]

On 4/2/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> I think the missing namespace in SREG1.0 can cause problems; take
> this example:

I was not proposing that we drop the namespace. Just that we don't
introduce a new URI when the protocol is otherwise identical, and
instead just use the existing type URI as a namespace URI.

That is, an SREG 1.1 request looks like:

openid.ns.s=http://openid.net/sreg/1.0&openid.s.nickname=j3h

not:

openid.sreg.nickname=j3h

If you use "sreg" as the namespace alias, SREG 1.1 is identical to SREG 1.0.

Is that clearer?
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

SREG namespace URI rollback

[Josh Hoyt]

I'd like to change the simple registration specification so that it
uses the type URI that is currently in use in at least PIP and
MyOpenID as the namespace URI instead of defining a new value.

As far as I can tell, the only difference between the 1.0 and 1.1
simple registration specifications is adding the namespace URI. The
names and meanings of all of the fields are the same, so there is no
compatibility issue, and the URI for 1.0 is already reserved (because
it's used as the Type URI in XRDS documents).

In short, I don't think that the SREG namespace/type URI should change
until there are incompatible changes to the simple registration
specification.

So are there any objections to rolling the URI back to
 from
?

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

Re: Attribute Exchange pre-draft 5

[Josh Hoyt]

On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> - Clarified that a fetch response parameter MUST be sent for each
> requested attribute, with an empty value if the user did not supply one.
> along the lines of the above, so that the RP can fallback to
> alternative data collection methods

What about attributes whose value could reasonably be an empty string?
It would be reasonable to answer "don't do that," I'm just curious how
you expect this case to be handled.

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

Re: Attribute Exchange pre-draft 5

[Josh Hoyt]

On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> One feature we didn't figure out yet if its benefits would be worth
> the added complexity:
> - in a fetch response, distinguish between attributes
> that the user didn't *want* to release and the ones
> not supported by the OP.
>
> What do you think?

My intuition is that a server could advertise what attributes it
supports rather than including this information in a user-specific
response. So, -0.5 on this. If it does go in, I'd say -1 on making it
REQUIRED.

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

Re: Attribute Exchange pre-draft 5

[Josh Hoyt]

On 3/26/07, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> - Added ax.mode parameters to all messages, to unambiguously identify
> the message types; the values are:
> fetch_request
> fetch_response
> store_request
> store_response_success
> store_response_failure
> This allows implementers to decouple the processing of the underlying
> OpenID Auth message and the extension layer.

What about using a different namespace URI for each message?

I was thinking:
  http://openid.net/srv/ax/1.0#fetch_request
  http://openid.net/srv/ax/1.0#fetch_response
  http://openid.net/srv/ax/1.0#store_request
  ...

That eliminates the need for an extra parameter, but makes the auth
message processing unambiguous. It's also clear to human readers that
those namespaces are related, since they are in the same document.

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

Re: Version 2.0 soon final?

[Josh Hoyt]

On 3/20/07, Granqvist, Hans <[EMAIL PROTECTED]> wrote:
> OpenID 2.0 has been cooking for quite a while. When
> will 2.0 be FCS?

What does FCS [1] mean?

Josh

1. http://en.wikipedia.org/wiki/FCS
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: modulus and generator optional in association requests

[Josh Hoyt]

On 3/20/07, Granqvist, Hans <[EMAIL PROTECTED]> wrote:
> Once something complex is optional, typically few will
> implement it, which means you can run into the inverse:
> implementations that do supply optional values run into parties
> that cannot treat those values correctly.

They are optional in OpenID 1, so the cat's already out of the bag.

I see no reason to make them required in OpenID 2, since this case
will already need to be implemented.

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

Re: Proposal: An anti-phishing compromise

[Josh Hoyt]

On 2/2/07, john kemp <[EMAIL PROTECTED]> wrote:
> Don't get me wrong - I think it's a good idea for the OP to make a
> statement about the authentication method used (although I would prefer
> it to say something like
> authn_method="urn:openid:2.0:aqe:method:password", rather than
> phishable="yes"). That points to AQE, as David mentioned already.

A browser plug-in, like sxipper, that uses a username and (a
generated, non-user-visible) password internally and will only submit
it to the correct OP can't be phished.

Is this a different kind of authentication than "password"? I don't
think so. Is it phishable? I think that the OP can reasonably say that
it is not. Therefore, I think that the authentication mechanism is (or
at least can be) independent from whether the authentication channel
is phishable.

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

Re: OA2.0d11: Minor nit-pick regarding normalization

[Josh Hoyt]

On 2/1/07, Martin Atkins <[EMAIL PROTECTED]> wrote:
> The normalization table in appendix A.1 lists several examples of the
> normalization of URIs. The last few examples are as follows:
>
>  http://example4.com/ => http://example4.com/
>  https://example5.com/ => https://example5.com/
>  example6.com => http://example6.com
>
> I believe that the last example should instead normalize to:
>  http://example6.com/

You're right that the example needs to have the slash added. I don't
think that we need any extra wording because RFC3986, which we
reference for the normalization rules says:

   a URI that uses the generic syntax for authority with an
   empty path should be normalized to a path of "/".

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

Re: Proposal: An anti-phishing compromise

[Josh Hoyt]

On 2/1/07, Paul Madsen <[EMAIL PROTECTED]> wrote:
> Hi Josh, do I understand correctly that the motivation for your proposal
> is not 'fix' the phish problem, but to simply hilite it so that RPs will
> begin to put pressure on their OPs to move to something beyond passwords?
>
> If this is the case, perhaps allowing an SP to add it to its request for
> authentication would give a direct (and loggable)  mechanism by which
> the RP can provide feedback to the OP product managers?

What's an SP as opposed to an RP?

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

Proposal: An anti-phishing compromise

[Josh Hoyt]

Hello,

I've written up a proposal for an addition to the OpenID
Authentication 2.0 specification that addresses the phishing problem.
I've had some off-list discussion of it, and I think it may strike the
right balance. Please provide feedback.

Josh

Background
==

We have had a lot of good discussion about how phishing relates to
OpenID. There seems to be consensus that the OpenID Authentication
spec should address these issues, but not consensus on how that should
happen.

The ways that OpenID can potentially make phishing worse:

 * Redirects to your provider are a fundamental part of the flow of
OpenID, so being redirected to a phishing site is easy to miss

 * Every relying party (necessarily) needs to know who the provider
is in order to verify the authentication response. This means that the
site knows what UI it needs to use to phish (and even worse, it can
just proxy the user to the provider)

I think these two issues cover what makes phishing potentially a
greater threat when using OpenID.

Although these problems are significant, if a user can authenticate to
their OpenID provider through an "non-phishable" mechanism, OpenID can
make the phishing problem *less* of a threat, because there are fewer
places that will need to ask for credentials.

Other relevant issues:

  * There is no universally deployed solution to the phishing problem

  * There is not even a universally *accepted* solution to the phishing problem

  * Any technology that prevents phishing will require user-agent
support or else will fundamentally change the flow of OpenID (prevent
relying-party-initiated sign-in)

  * OpenID is intended to be deployed without requiring specific
technologies to be present in the user-agent

  * Any general anti-phishing technology can be applied to OpenID

Proposed Change
===

Add a single, required, boolean field to the authentication response
that specifies whether or not the method the OP used to authenticate
the user is phishable. The specification will have to provide
guidelines on what properties an authentication mechanism needs to
have in order to be "non-phishable." The field is just meant to
indicate that the authentication mechanism that was used is not a
standard "secret entered into a Web form."

Analysis


This proposal is a simplification of the Assertion Quality Extension
[1] (AQE), and is essentially the same as what Ben Laurie proposed
earlier [2]. It does not attempt to replace the AQE or require it for
authentication in general.

Benefits


The proposal is trivial implement, it acknowledges that phishing is a
problem, and forces implementers think about it. If more assurances
are required, then the AQE, whitelists, and other mechanisms still
need to be employed. This field just sets a minimum bar.

I think that this is the right information to require, because it
addresses this one thing that makes OpenID potentially worse for
security, but it does not mandate specific technologies.

It pushes the liability for phishing relying parties to OpenID
providers, who are the ones who should be responsible for taking
measures to prevent phishing. IANAL, so I don't know if this has any
real teeth, but it does make it clear to people who are implementing
OpenID providers that it is intended to be their responsibility to
deal with the phishing issues.

Drawbacks
-

It may be tricky to define what is meant by "non-phishable."

There is no way for a Relying Party to *ensure* that the OpenID
provider indeed uses "non-phishable" authentication.

If libraries are used, the library user may not read the relevant
parts of the specification about phishing, and so may remain ignorant
of the phishing issues.

Why this should be in the core spec
---

I believe that this one piece of information would be required more
often than not, given the phishing implications. The prominence of
being in the core specification makes it harder to ignore the phishing
problem.

References
==

1. http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html
2. http://openid.net/pipermail/general/2007-January/001340.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: DRAFT 11 -> FINAL?

[Josh Hoyt]

On 1/30/07, Recordon, David <[EMAIL PROTECTED]> wrote:
> Yeah, I'm not a big fan of openid2.* though it was the simplest method
> of fixing up HTML discovery to work with multiple protocol versions.  I
> know Josh thought about this more than I did though.

1. Before authentication is initiated, the RP needs to determine what
the protocol is. This could be done via discovery on the OP, but there
has been general rejection of adding yet another discovery step.

2. A user may have one service that provides OpenID 1 and another that
provides OpenID 2. If this is the case, then the version information
needs to be bound to the link tag that contains the information.

Given (1), the information needs to be embedded in the HTML markup.
Given (2), the information needs to be tied to the specific link tag.

For example:

  http://op.example.com/openid1";>
  http://op.example.com/openid2";>

vs.
  http://op.example.com/openid1";>
  http://op.example.com/openid2";>
  http://specs.openid.net/auth/2.0";>

While it is true that since the link relationship names changed, the
"openid2" is technically redundant, I think it is much clearer to
everybody what is going on if the link relationship contains the
version number. If the protocol version were to keep changing, I'd
argue for a different solution.

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

Re: HTML parsing in HTML-based discovery

[Josh Hoyt]

On 1/26/07, Martin Atkins <[EMAIL PROTECTED]> wrote:
> 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.

While our parser [1] is implemented using regular expressions, I don't
think it's what most people mean when they say "parsing with regexps."

The reason that (most of) the JanRain libraries don't use an HTML
parser is because I was afraid that "loose" parsing of HTML could lead
to OpenID discovery markup being recognized in parts of the document
other than the head, leading to vulnerabilities where someone could
hijack a URL by e.g. adding a malicious comment to a blog.

When implementing this parser, I tried to be aware of both the varied
markup that exists across the Web and the security implications of
different parsing strategies. In short, the parser tries to recognize
any OpenID markup that is unambiguously in the  of an HTML
document and reject anything else. If you're interested in the
details, read the comments at the top of the file (again, [1])

The parser does not work for some valid XHTML cases, most notably
using an explicit XML namespace for the XHTML tags. It also does not
deal with some cases of valid HTML 4. [2] I am sure that there are
other cases in which valid markup is not recognized. My implementation
and design strategy was to implement something that is immune to the
attacks that I could conceive and work for the vast majority of the
cases that exist in the wild.

Ironically, another reason that we implemented this parser instead of
using an (X)HTML parsing library is that according to the spec, only
certain entities should be processed in the  tag's attributes,
and a real (X)HTML parser would process all of the entities. It's
arguable whether processing the entities is right or wrong, because
the user who marked up the page is violating the spec, but I figured
that by following the spec exactly, the users who put in this markup
would have a more consistent experience (i.e. their markup would be
broken for all libraries rather than accepted by some and rejected by
others)

In an ideal world, we'd be able to specify that the document was e.g.
valid XHTML and just use a nice, strict parser on it. The reality of
the situation forces us to deal with the markup that's out there,
which leads to trade-offs, no matter how we choose to deal with that
markup.

Josh

1. 
http://www.openidenabled.com/resources/darcsweb?r=python-openid;a=headblob;f=/openid/consumer/parse.py
2. http://www.intertwingly.net/blog/2006/12/28/Unobtrusive-OpenID#c1167404328
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11

[Josh Hoyt]

On 1/22/07, Ben Laurie <[EMAIL PROTECTED]> wrote:
> > On 1/22/07, Ben Laurie <[EMAIL PROTECTED]> wrote:
> > > OK, the idea is pretty simple. Rather like the "OpenID Authentication
> > > Security Profiles" you have a profile where the RP states what kind of
> > > End User/OP authentication is acceptable to it. Sites with low/zero
> > > value attached to the login can accept any kind of EU/OP auth, whereas
> > > high value sites can require "unphishable" auth.
> >
> > I like the sound of this proposal, but I don't see how the RP could
> > know whether the OP is actually using "unphishable" authentication
> > when that kind of authentication is requested. Is it necessary for the
> > RP to be able to tell for sure, and if so, how could it tell?
>
> No, I don't think it is necessary. If users want to trust their
> identity to OPs that lie, that's their decision.

In that case, I think this could just be part of the "Assertion
Quality Extension." [1] I haven't been involved in that specification
at all, but my understanding is that it provides a way of expressing
what kind of authentication the RP would like to have when a request
is made to the OP.

Josh

1. http://openid.net/specs/openid-assertion-quality-extension-1_0-01.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11

[Josh Hoyt]

Ben,

On 1/22/07, Ben Laurie <[EMAIL PROTECTED]> wrote:
> OK, the idea is pretty simple. Rather like the "OpenID Authentication
> Security Profiles" you have a profile where the RP states what kind of
> End User/OP authentication is acceptable to it. Sites with low/zero
> value attached to the login can accept any kind of EU/OP auth, whereas
> high value sites can require "unphishable" auth.

I like the sound of this proposal, but I don't see how the RP could
know whether the OP is actually using "unphishable" authentication
when that kind of authentication is requested. Is it necessary for the
RP to be able to tell for sure, and if so, how could it tell?

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

Re: HTML-Based Discovery with OP Identifiers

[Josh Hoyt]

On 12/28/06, David Recordon <[EMAIL PROTECTED]> wrote:
> That is a bit confusing to parse so we were looking at re-wording it.  Issue
> is "Claimed Identifier" is defined as possibly being a "User-Supplied
> Identifier" which in turn can be an "OP Identifier" thus making this
> paragraph fall apart.

>From 7.3.1:

 If the end user did not enter an OP Identifier, the following
information will also be present:

* Claimed Identifier
* OP-Local Identifier

The Claimed Identifier can not be an OP identifier. Therefore, I think
there is not a problem with the way that HTML discovery has been
specified. I don't have time to write up why right now, but I'm -1 on
adding a type field to HTML discovery.

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

Re: Consistency of negative responses to checkid_immediate requests

[Josh Hoyt]

Reviving an old thread...

On 12/14/06, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> On 14-Dec-06, at 12:13 AM, Josh Hoyt wrote:
> > On 12/13/06, Martin Atkins <[EMAIL PROTECTED]> wrote:
> >> 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.
> >
> > That's true, but the RP will probably need to handle the success case
> > differently for immediate mode anyway (e.g. it will have to do AJAX to
> > update the page) so I expect it to have a specific return_to URL for
> > immediate requests. Since using a different return_to is trivial, I
> > prefer the consistency of negative responses.
>
> The current / v1 modes will need to be mentioned in the compatibility
> section, and also implemented. Not sure if this simplification will
> then still be worth.

Since the user_setup_url parameter is now gone, there is no way to
differentiate between a broken/truncated response and a cancel
response to an immediate mode request.

I think that there needs to be *some* positive way to identify
cancellation of immediate mode requests, rather than depending on lack
of other parameters. I'd be happy with any of these ways to positively
identify a cancel response to checkid_immediate:

 1. re-using "cancel" as I suggested above

 2. introducing a new mode (e.g. "setup_needed" )

  3. adding a parameter that the id_res response is an immediate
cancellation (e.g. openid.setup_needed=true)

I no longer buy the argument about having to support the OpenID 1
mechanism in the library, since cancellation of an immediate mode
response is already indicated differently between OpenID 1 and 2, so
it's really just a matter of what goes into the OpenID 2 code path
rather than whether the two code paths exist.

Pseudo-code for the current approach:

def isSetupNeeded():
  if this is OpenID 1:
return whether there is a user_setup_url parameter

  if this is OpenID 2:
# This is the branch that I want to change
return whether there are any other OpenID parameters passed at all

Thoughts?

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

Re: [OpenID] inconsistent "openid." prefix

[Josh Hoyt]

On 12/17/06, Manger, James H <[EMAIL PROTECTED]> wrote:
> OpenID Authentication 2.0 predraft 11 uses the "openid." prefix 
> inconsistently.  For instance, §5.2.3 has dot-points for "openid.mode", 
> "openid.error", "openid.contact"…, whereas §5.1.2.2 has dot-points for 
> "error", "contact"….
> The data format example (§4.1.3) uses "mode" and "error" keys in the 
> Key-Value Form encoding, but "openid.mode" and "openid.error" in the 
> x-www-urlencoded example in the very next paragraph.  I assume it should be 
> "openid.mode" and "openid.error" everywhere.

If the message is sent as an HTTP request (GET or POST), the keys
start with "openid."

If the message is sent as a reply to a HTTP POST (in Key-Value form),
the keys do not start with "openid."

I hope this will be clearer in the (soon to be released) next draft.


> Text such as
>   Value: "associate"
> or
>   Default: "HMAC-SHA1"
> appears throughout the spec.  A assume the quotes do NOT appear in the 
> protocol.  A sentence to this effect in §4.1 Protocol Messages would help, as 
> would more comprehensive examples.
> Add this sentence to §4.1:
> "Specific values are shown in double quotes within this specification (eg 
> Value: "associate") but the quotes do not appear in the protocol messages (eg 
> openid.mode=associate)."

Thanks for the suggestion. I'll add it.

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

Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> >> 10 Responding to Authentication Requests
> >>
> >> First sentence:
> >>> When an authentication request comes from the User-Agent via
> >>> indirect communication (Indirect Communication), the OP SHOULD
> >>> identify the User-Agent, and determine whether the end user
> >>> wishes to complete the authentication.
> >>
> >> I have no idea what the term "identify" means here. Do you mean:
> >>> When an authentication request comes from the User-Agent via
> >>> indirect communication (Indirect Communication), the OP SHOULD
> >>> determine the validity of the current session of the User-Agent
> >>> with the OP, and -- with or without direct interaction with the
> >>> user, this is left to implementors -- determine whether the end
> >>> user wishes to complete the authentication with this particular RP.

Re-worded in 
http://openid.net/svn/listing.php?repname=specifications&path=%2F&rev=235&sc=1

New text:

  When an authentication request comes from the User-Agent via
indirect communication
  (Indirect Communication), the OP SHOULD determine that an authorized end user
  wishes to complete the authentication. If an authorized end user
wishes to complete the
  authentication, the OP SHOULD send a positive assertion (Positive
Assertions) to the
  Relying Party.

  Methods of identifying authorized end users and obtaining approval
to return an OpenID
  Authentication assertion are beyond the scope of this specification.

I think that's all the issues that were in my court. Did I miss anything?

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

Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> >> Section 4.1.1 - Key-Value Form Encoding
> >>
> >> If in the key-value form, I wish to transmit a value that includes
> >> a '\n', what am I supposed to do?
> >
> > Encode it such that it doesn't have a '\n' in it, e.g using base64.
> > If  '\n' was allowed, the protocol would permit the kind of attack
> > described in this thread:
> > http://openid.net/pipermail/specs/2006-November/000901.html
>
> I understand that is one possible fix. What about we define one of
> the possible fixes as the "canonical" fix for text data, otherwise
> different implementors will implement different fixes (base64, C-
> style \n, URL-style %0D%0a, ... ) and interop will suffer.

I'm uncomfortable defining an escaping mechanism when there are
different possibilities that are appropriate for different contexts. I
think that extension authors will define an appropriate scheme for the
problem that they are solving (e.g. if it's binary data, use base64),
and everyone who is using that extension will use that same encoding,
so there will not be interoperability issues.

If there were multiple extensions defining escaping mechanisms today,
and they agreed, then I might agree to specify one, but there are not,
so I'd rather leave it open.

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

Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> >> 14. Discovering OpenID Relying Parties
> >>
> >> Can I ask to append the following sentence?
> >>> The  element is OPTIONAL for this use of the
> >>>  element. If the  element is not given, it
> >>> is assumed to be the URI on which Yadis discovery was performed
> >>> to lead to the XRDS document.
> >>
> >> This would be a useful default that would come very handy. And
> >> right now, the way it is written, this is underdefined in any case.
>
> Resolution?

I made the section explicit on requiring the  element to be
present. [1] This isn't what you asked for, but it avoids the issue of
e.g. what to do if the discovery was performed on an XRI. I hope this
is satisfactory.

Josh

1. 
http://openid.net/svn/listing.php?repname=specifications&path=%2F&rev=213&sc=1
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

Oops, forgot to copy the list...

On 12/14/06, Josh Hoyt <[EMAIL PROTECTED]> wrote:
> On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> > >> 9.1. Request Parameters
> ...
> > >>> Note: If an OP-SPecific Identifier is not supplied, the
> > >>> Claimed Identifier is considered to have the same as the OP-
> > >>> Specific Identifier. If neither value is present, the assertion
> > >>> is not about an identifier, and will contain other information in
> > >>> its payload, using extensions (Extensions).
> > >
> > > This doesn't seem right; I read your text like this:
> > >
> > >> "If an OP-Specific Identifier is not supplied"
> > > and therefore openid.identity = "http://openid.net/
> > > identifier_select/2.0"
> > >> "the Claimed Identifier is considered to have the same as the OP-
> > >> Specific Identifier."
> > > openid.claimed_id = "http://openid.net/identifier_select/2.0";
> > >
> > > Which is fine, but doesn't cover the remaining cases, i.e. when
> > > Claimed Identifiers / OP-Specific Identifiers *are* supplied.
> > >
> > > The original / current wording does cover these cases, albeit I
> > > admit it is not very easy to read.
> >
> > So I modify my request to modify the wording in a way that it is
> > easier to read.
>
> Attempted.
>
> See 
> http://openid.net/svn/listing.php?repname=specifications&path=%2F&rev=201&sc=1
> and 
> http://openid.net/svn/listing.php?repname=specifications&path=%2F&rev=209&sc=1
>
> Josh
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> >> 7.1 Initiation
> >>
> >> Given recent discussions on logo and User Experience, this needs
> >> to be different. Instead of:
> >>
> >>>  To initiate OpenID Authentication, the Relying Party SHOULD
> >>> present the end user with a form that has a field for entering an
> >>> Identifier.
> >>>
> >>> It is RECOMMENDED that a Relying Party place the OpenID logo at
> >>> the beginning of the form field where the end user enters their
> >>> Identifier. This aides in end user recognition that they can use
> >>> an OpenID enabled Identifier at the Relying Party.
> >>
> >> Better:
> >>
> >>> This document does not define a user experience. It is
> >>> RECOMMENDED that implementors follow the OpenID user experience
> >>> if and when such an OpenID user experience has been defined in a
> >>> separate document.
>
> Proposed resolution?

I've taken out the logo recommendation and left it with an input field
in a form with the appropriate "name" attribute. The user-experience
document won't contradict *that* much, and it's a technical necessity
(for e.g. smart software agents to detect the login field).

See 
http://openid.net/svn/listing.php?repname=specifications&path=%2F&rev=212&sc=1

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

Re: Consistency of negative responses to checkid_immediate requests

[Josh Hoyt]

On 12/14/06, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> On 14-Dec-06, at 12:13 AM, Josh Hoyt wrote:
> > On 12/13/06, Martin Atkins <[EMAIL PROTECTED]> wrote:
> >> 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.
> >
> > That's true, but the RP will probably need to handle the success case
> > differently for immediate mode anyway (e.g. it will have to do AJAX to
> > update the page) so I expect it to have a specific return_to URL for
> > immediate requests. Since using a different return_to is trivial, I
> > prefer the consistency of negative responses.
>
> The current / v1 modes will need to be mentioned in the compatibility
> section, and also implemented. Not sure if this simplification will
> then still be worth.

That's a good point. I guess it comes down to how long OpenID 1.1
support will be necessary. If it's a long time (effectively forever)
then it's definitely not worth it. If it's a relatively short period
of time, then I think it is worth it for the cleaner spec.

Unless someone agrees that it'd be worth it, I'll leave it alone.

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

Off-topic: Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

On 12/14/06, Joaquin Miller <[EMAIL PROTECTED]> wrote:
>> I have changed that text from "needs to" to MUST, although I think that the
>> sentence before that (The end user's input MUST be normalized into an
>> Identifier) is pretty unambiguous.
>
>  I feel this is an excellent change.  This style should be followed
> throughout.
>
>  The problem with 'needs to' and 'MUST' in the same document is that it
> leaves the reader this little puzzle to puzzle over:  What is the normative
> difference between 'needs to' and 'MUST'?  Why is 'needs to' used here and
> 'MUST' there?  Is 'needs to' weaker than 'MUST'? Is 'needs to' stronger than
> 'SHOULD'?

I doubt that the "needs to" wording would have ever caused any
problems with implementation. The sentence before states that you MUST
normalize the input. The "needs to" was describing a condition that is
necessary to check in order to perform the normalization. Anyone who
was attempting to implement the normalization algorithm would see that
it is necessary to determine the type of the input before continuing.

I think that words like MUST and SHOULD are not necessary when
describing how to do something whose importance has already been made
clear (by a MUST, etc.). I have a hard time reading prose that uses
those words excessively, because if they are over-used, they become
noise ("you already said I MUST normalize").

Anyway, I think the OpenID 2.0 Authentication specification is pretty
consistent about using the appropriately strong wording when it's not
already clear whether something is required, so I think this
discussion is mostly academic. Feel free to make requests if there are
specific parts whose compliance is not obvious.

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

Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

On 12/14/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> So you believe that it is tight enough that if you and I implement
> the spec, and somebody types the exact same character string into
> both of our implementations, it will produce the exact same result,
> regardless what the character string was?

Yes, that's what I think. :)

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

Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

(I will be addressing the remaining issues that you brought up one at a time)

On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> >> 7.2 Normalization
> >>
> >> I'm not sure that this -- all of which is OPTIONAL -- should be in
> >> this document. I would suggest to either make it MANDATORY -- or
> >> to take it out of this document and refer to a User Experience
> >> document instead.
> >>
> >> The problem is that if the user can type in something incomplete
> >> at site A, and then types in the same incomplete thing at site B,
> >> it may work at A but differently at B, which is no good. So either
> >> make these rules MANDATORY, or delegate them into the user
> >> experience.
> >
> > Normalization is not optional at all - not sure why you understood
> > it was. Maybe that section needs to be clarified, if you can point
> > it to us.
>
> I am referring to par 1 sentence 2, where is says "needs to" instead
> of "MUST ... according to the following algorithm".
> Then to the entire paragraph 2, which says SHOULD.
>
> I'd like an algorithm that produces the same normalized identifier
> from the same entered text string, regardless of site.

I have changed that text from "needs to" to MUST, although I think
that the sentence before that (The end user's input MUST be normalized
into an Identifier) is pretty unambiguous.

Paragraph two about normalizing XRIs I think was David's text, so I
guess I'll wait for his response about that. I think he's on vacation.

Other than the SHOULD for recognizing XRI global context symbols and
adding the xri:// prefix, I think that the normalization section is
pretty tight and will not lead to inconsistencies in implementation.

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

Re: Consistency of negative responses to checkid_immediate requests

[Josh Hoyt]

On 12/13/06, Martin Atkins <[EMAIL PROTECTED]> wrote:
> 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.

That's true, but the RP will probably need to handle the success case
differently for immediate mode anyway (e.g. it will have to do AJAX to
update the page) so I expect it to have a specific return_to URL for
immediate requests. Since using a different return_to is trivial, I
prefer the consistency of negative responses.

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

Consistency of negative responses to checkid_immediate requests

[Josh Hoyt]

In OpenID 2.0, we have removed the "setup_url" parameter from negative
responses to "checkid_immediate" requests. This means that a negative
response to a "checkid_immediate" request looks like:

http://rp.com/return_to?openid.mode=id_res&openid.ns=[OpenID 2.0 ns]

A negative response to a "checkid_setup" request looks like:

http://rp.com/return_to?openid.mode=cancel&openid.ns=[OpenID 2.0 ns]

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.

Does it sound reasonable?

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

Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

On 12/12/06, Joaquin Miller <[EMAIL PROTECTED]> wrote:
>  How about one of these:
>
>> When a message is sent as a POST, OpenID parameters MUST be sent only in
>> the POST body and the parameters processed MUST be only those from the POST
>> body.
>
>>When a message is sent as a POST, OpenID parameters MUST be sent only in
>> and processed only from the POST body.
>
>  Instead of:
>
>> When a message is sent as a POST, OpenID parameters MUST only be sent in and
>> processed from the POST body.
>
>  (I feel the first of the two alternative above captures the intention much
> better.  We are aiming to make each clause of this document clear for folks
> who don't already know what we have in mind, right?)

I think Johnny's wording is fine, but if it were to be changed, I
would prefer the second of the two alternatives that you proposed.

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

Re: Comments on Auth 2.0 - Pre-Draft 11

[Josh Hoyt]

On 12/11/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> >> It is unclear which of those parameters are MANDATORY and which
> >> are OPTIONAL

Thanks for your detailed reading and feedback. I'm not commenting in
this message about any specific point that you have, but just pointing
out that RFC2119 does not define MANDATORY.

Today I'll be talking to Johnny and hopefully we'll have some good
feedback about specifics after that.

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

Re: [security] security hole in signature algorithm

[Josh Hoyt]

On 11/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> By manipulating the return_to parameter, an attacked can impersonate
> another user at an RP.

it's hard to do a careful reading of your message with mhy 2-year-old
playing piano in the background, but I don't think I understand your
attack.

I don't see any KV form strings in your description, and those are the
things that get signed. In KV form, the pairs are indeed suffixed with
a newline, which is the reason that newlines are not allowed.

the x-www-urlencoded string:

  foo=bar&baz=quux

looks like:

foo:bar
baz:quux

in KV form.

Am I missing something?

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

Re: Went Through it With Brad

[Josh Hoyt]

On 11/8/06, Recordon, David <[EMAIL PROTECTED]> wrote:
> 2) 7.3.3 basically deprecates HTML-based discovery, saying that it is a
> way to know that the IdP is using Auth 1.1.  While I know we believe
> Yadis will be used in most applications, I hypothesize that the
> simplicity of HTML-based discovery will have it continue to prevail.  I
> thus would propose we remove the sentence saying that this is a way to
> know that an IdP is running version 1.1.

Yeah, it does. The justification for this is that there is no way to
specify a version for the server, so we have to assume something, and
since HTML discovery already used in 1.1, that's the only reasonable
assumption to make. I see two ways out of this:

1. Add another "rel" value to the HTML discovery for OpenID 2:
  

2. Add some way of doing discovery on the endpoint URL for determining
the version, so it doesn't have to be part of the user's XRDS or HTML
document

Either one of these would let us keep the nice, simple HTML discovery
mechanism for 2.0.

Thoughts or ideas?

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

Re: Few comments on Draft 11

[Josh Hoyt]

On 11/10/06, Prasanta Behera <[EMAIL PROTECTED]> wrote:
> #1: Section 10.1
> > Value: Comma-separated list of signed fields. Note: This entry consists of
> the fields without the "openid." prefix that the signature covers. This list
>
> > MUST contain at least "return_to" and "response_nonce", and if present in
> the response, "disco_id" and "identity". For example,
>
> > "identity,disco_id,return_to,response_nonce".
>
> It should be "if present in the response, "disco_id" and/or "identity   … "
> since identity is a optional field.

As of draft 11, disco_id is present if, and only if, identity is
present, so I think the wording is OK. Maybe that relationship should
be emphasized elsewhere.

> #2: Section 11.3
>
> >If the Claimed Identifier was not present in the request ("openid.identity"
> was "http://openid.net/identifier_select/2.0";), the Relying
> Party MUST perform discovery on the Identifier in the response to make sure
> that the IdP is authorized to make assertions about the Identifier.
>
> Why RP needs to do a discovery again on the identifier asserted by the IDP
> when the IDP asserted it? (or may be I mis-read it)

The relying party must do discovery to determine that the IdP that
made the assertion is authoritative for that identifier.

For example, if a reponse comes back from "http://rogue-idp.com/"; for
"http://openid.yahoo.com/joshhoyt";, the relying party will know not to
accept it after performing discovery on
"http://openid.yahoo.com/joshhoyt";.

Does that clear it up?

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

Re: Yet Another Delegation Thread

[Josh Hoyt]

On 10/26/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> On 26-Oct-06, at 8:27 AM, Josh Hoyt wrote:
> > Requiring this discovery adds another (redundant) HTTP request to the
> > authentication process, which takes time. I'd like to be able to
> > improve the "User Experience" by implementing an IdP that would verify
> > the binding occasionally, but not *every time* the user authenticates.
>
> I would assume that some caching of HTTP requests would be allowed
> depending on the HTTP headers sent by the site serving the portable
> identifier document. Since the IdP is likely involved in all identity
> transactions for the user, there would be many cache hits and the
> extra traffic not that significant. Note this is also a server to
> server request, which should be much less significant then client to
> server requests.

But if the IdP's cache does not match the RP's cache, there is a hole.

> It would seem this all boils down to optimizing one potential HTTP
> request.

What about http://openid.net/pipermail/specs/2006-October/000735.html ?

> Has anyone laid out how many requests happen in a transaction?

About 1000 ;)

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

Re: Yet Another Delegation Thread

[Josh Hoyt]

On 10/26/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> If the IdP is not doing discovery per your previous comment, then
> compromising the RP's discovery is sufficient hijack a user's
> identifier, and it likely is easier to compromise an RP then an IdP,
> and we should move complexity to IdPs to an RP all other things being
> equal.

Compromising a relying party's discovery is sufficient in *any case*
to hijack an identifier. The discovery just needs to return a
different IdP.

Not letting the RP verify *all* of the discovered information adds
another place (the IdP) where compromising discovery is a valid
attack.

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

Re: Yet Another Delegation Thread

[Josh Hoyt]

On 10/26/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> >  * If the IdP-specific identifier is not checked by the relying
> > party's discovery, the IdP MUST do discovery on every request to
> > ensure that it's not making an assertion based on stale information.
>
> Which is probably a good idea. :-)
> If the IdP is sending both identifiers in a signed response, then
> they both should be valid.

Requiring this discovery adds another (redundant) HTTP request to the
authentication process, which takes time. I'd like to be able to
improve the "User Experience" by implementing an IdP that would verify
the binding occasionally, but not *every time* the user authenticates.

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

Re: OpenID user experience (new mailing list)

[Josh Hoyt]

On 10/25/06, Johannes Ernst <[EMAIL PROTECTED]> wrote:
> Nothing prevents you from routing all of those into a single in-box ;-)

Although it can be hard to mentally keep the context of the
discussion, and to keep appropriate discussion on the appropriate
list. A usability discussion that affects security and requires a spec
change might need to be copied to three lists.

I think that the traffic on this list will probably tail off to a
reasonable level once the 2.0 spec is marked as done.

'course, it's hard to un-create a mailing list, and "security" and
"user experiece" have already been created.

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

Re: Yet Another Delegation Thread

[Josh Hoyt]

On 10/25/06, Martin Atkins <[EMAIL PROTECTED]> wrote:
> > Then why send it?
>
> That's what I've been asking all along! :)
>
> What exactly do we imagine the IdP doing with the claimed_identifier?
> The main answer I've seen anyone post so far is that the IdP will use it
> to greet the user

The primary reasons that I think sending the claimed identifier are useful:

  1. The relying party no longer has to be responsible for managing
state for this transaction

  2. The IdP can use the claimed identifier to choose an appropriate
persona and other behaviour, such as auto-approval differently for
different identifiers

  3. The user experience can be more consistent. Even if the IdP
greets you as Martin, if you use more than one identifier with that
IdP, it's a much better experience for the IdP to remind you when you
are making a decision which identifier you will actually be logged in
as. The IdP can't do that if it gets only an IdP-specific identifier.

The primary reasons that I think it's useful to send the IdP-specific
identifer as well:

  1. The IdP is not *responsible for* doing discovery, so:

 * It's possible to be more efficient, since discovery is not
duplicated by the IdP and RP. This is mostly just a nice side-effect
and is not the primary motivation for my support.

 * there is one less place where spoofing discovery is a valid
attack. If the relying party is not checking the IdP-specific
identifier, compromising an IdP's discovery is sufficient to hijack a
user's identifier.

 * If the IdP-specific identifier is not checked by the relying
party's discovery, the IdP MUST do discovery on every request to
ensure that it's not making an assertion based on stale information.

  2. Checking the response is more strict, since ALL of the discovered
information must be verified.

Put these together, and it's my case for sending both identifiers.

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

Re: Yet Another Delegation Thread

[Josh Hoyt]

On 10/25/06, Pete Rowley <[EMAIL PROTECTED]> wrote:
> Josh Hoyt wrote:
> > If the user uses different IdP-specific identifiers for each portable
> > identifier, I don't see how they can be correlated.
>
> Unless I mis-understand the the OpenID discovery mechanism - at the
> point of discovery, which can be done out of band in a spider like web
> harvesting fashion.  Any one discovery point contains your identity map.

I think you misunderstand it. Each identifier specifies the IdP and
possibly IdP-specific identifier to use for itself. There is no global
"identity map."

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

Re: Yet Another Delegation Thread

[Josh Hoyt]

On 10/25/06, Pete Rowley <[EMAIL PROTECTED]> wrote:
> > The IdP can issue as many identifiers as it wants to the user, and the
> > user can use a different IdP-specific identifier for each of their
> > separate portable identifiers.
>
> I don't understand why this would help - it really doesn't matter if I
> use one IdP with multiple identifiers or multiple IdPs or how many
> portable identifiers I use if all of them can be correlated through
> specified OpenID discovery mechanisms.

If the user uses different IdP-specific identifiers for each portable
identifier, I don't see how they can be correlated.

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

Re: Yet Another Delegation Thread

[Josh Hoyt]

On 10/25/06, Pete Rowley <[EMAIL PROTECTED]> wrote:
> Is it a goal to not allow correlation of identifiers? If so, I do not
> think this meets that goal.
>
> Looking at the parties involved here, I necessarily have to trust my
> IdP, but I certainly don't want to trust RPs. So if there is to be
> leakage of information, it should go to the IdP, who is charged with the
> protection of my data. This appears to construct what amounts to a map
> of all my online identifiers nicely formatted so that a bot can harvest
> it easily. Perhaps non-correlation is a non-goal for this particular
> feature - but I would hope that it would be a high priority.

The IdP can issue as many identifiers as it wants to the user, and the
user can use a different IdP-specific identifier for each of their
separate portable identifiers.

Every proposal so far has had the IdP-specific identifier discovered
through the standard discovery mechanism, so this criticism would
apply to OpenID portable identifier support in general, not this
specific proposal.

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

Re: Yet Another Delegation Thread

[Josh Hoyt]

On 10/25/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> > I have said this several times already, but THE IDP DOES NOT HAVE TO
> > TRUST THIS INFORMATION.
>
> Then why send it?

Why send which one?
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Yet Another Delegation Thread

[Josh Hoyt]

On 10/25/06, Dick Hardt <[EMAIL PROTECTED]> wrote:
> > 2) Since the RP has to do discovery on the Claimed Identifier
> > anyway, if it
> > discovers a mapping between the Claimed Identifier and an IdP-Specific
> > Identifier, the RP can send the IdP-Specific Identifier to the IdP
> > and save
> > the IdP from having to repeat discovery.
>
> unfortunately that disco information could be modified in route, so
> the IdP can't trust it

I have said this several times already, but THE IDP DOES NOT HAVE TO
TRUST THIS INFORMATION.

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

Re: Two Identifiers - no caching advantage

[Josh Hoyt]

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.

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

Portable Identifier Support Proposal (patch)

[Josh Hoyt]

As requested [1], I have made a patch to the specification [2] that
specifies the "two-identifier" mechanism for portable identifier
support. It's attached to this message. The net effect is adding one
line to the source XML file.

I hope this proves useful in evaluating the proposal.

Josh

1. http://openid.net/pipermail/specs/2006-October/000478.html
2. http://openid.net/svn/listing.php?repname=specifications&rev=70&sc=1
  (openid.net specifications svn trunk, revision 70)
--- svn-track/openid-authentication.xml	2006-10-20 16:08:15.0 -0700
+++ work/openid-authentication.xml	2006-10-20 16:13:05.0 -0700
@@ -132,8 +132,8 @@
 referred to as a "URL" within this document, or http://www.oasis-open.org/committees/download.php/15376";
 >XRI.  An "Identifier" may be a Claimed Identifier,
-Delegate Identifier, IdP Identifier, or Verified Identifier,
-depending on context.
+IdP-Specific Identifier, IdP Identifier, or Verified
+Identifier, depending on context.
   
 
   
@@ -154,7 +154,7 @@
 that they own.
   
 
-  
+  
 An alternate Identifier that can be included in the discovery
 response.
   
@@ -751,21 +751,17 @@
   
 
   
-(optional) The normalized Identifier upon which
-discovery was performed. The Claimed Identifier is
-present unless the End User entered an IdP Identifier
-during initiation.
+(optional) The identifier that is the subject of this
+authentication request. This is the identifier upon
+which discovery was performed.
   
 
-  
-(optional)
- 
-The Identifier that the Relying Party SHOULD perform
-authentication using.  Upon successful authentication,
-the Relying Party SHOULD recognize the End User using
-the Claimed Identifier.  The Delegate Identifier can
-only be present when the End User enters a Claimed
-Identifier.
+  
+(optional) An identifier that allows an IdP to
+identify the user of a portable identifier. If no
+IdP-specific identifier is present in the discovered
+information, the Claimed Identifier is also the
+IdP-Specific Identifier.
   
 
   
@@ -820,8 +816,8 @@
   
 
   
-An  tag (optional) whose
-		text content is the Delegate Identifier.
+An  tag (optional) whose text
+content is the IdP-Specific Identifier.
   
 
   
@@ -928,7 +924,7 @@
   
 A  tag MAY be included with attributes
 "rel" set to "openid.delegate" and "href" set to the
-End User's Delegate Identifier
+End User's IdP-Specific Identifier
   
 
   
@@ -1362,11 +1358,24 @@
 
 
 
+  openid.portable
+  
+
+  Value: (optional) The Claimed Identifier.
+
+
+  Note: If the portable identifier is not specified,
+  it is assumed to be the same as the IdP-specific
+  identifier.
+
+  
+
+
+
   openid.identity
   
 
-  Value: (optional) Delegate Identifier when
-  available, otherwise the Claimed Identifier
+  Value: (optional) The IdP-Specific Identifier.
 
 
   Note: If this is set to the special value
@@ -1574,11 +1583,25 @@
 
 
 
+  openid.portable
+  
+
+  
+Value: (optional) The Claimed Identifier
+  
+  
+Note: If this value is absent, it defaults to the
+value of "openid.identity".
+  
+
+  
+
+
+
   openid.identity
   
 
-  Value: (optional) The Identifier about which the IdP
-  is making a positive authentication assertion.
+  Value: (optional) The IdP-Specific Identifier
 
 
   Note: The Identifier MAY be omitted if an extension
@@ -1664,13 +1687,12 @@
   Value: Comma-separated list of signed fields.
 
 
-  Note: This entry consists of the