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

2008-05-21 Thread 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


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

2008-05-21 Thread 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


Errata (was Re: openid:Delegate undefined namespace)

2007-12-13 Thread 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 openid:Delegate 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 openid:Delegate in the 2nd dot point in 14.2.1 to
 Delegate xmlns='http://openid.net/xmlns/1.0'
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


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

2007-11-01 Thread 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

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

2007-10-22 Thread 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


Announce: OpenID Authentication Draft 12 (finally)

2007-08-27 Thread 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

2007-06-20 Thread 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

2007-06-15 Thread 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?

2007-06-11 Thread 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

2007-06-11 Thread 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: Questions about IIW Identifier Recycling Table

2007-06-08 Thread 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

2007-06-08 Thread 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:
 a href= http://me.example.com#1234;http://me.example.com/a

 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 and the provider already need to store secrets.

I think 

Re: Questions about IIW Identifier Recycling Table

2007-06-07 Thread 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: Auth 2.0 Extensions: Namespace Prefixes

2007-06-05 Thread 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


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

2007-06-05 Thread 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: The WordPress User Problem (WAS: RE: Specifying identifierrecycling)

2007-06-05 Thread 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


Specifying identifier recycling

2007-05-30 Thread 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 http://josh.myopenid.com/. 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 http://josh.myopenid.com/1.

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

2007-05-29 Thread 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


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

2007-05-24 Thread 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


Realm spoofing spec patch

2007-05-24 Thread 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. 
http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn-327.html#return_to_verification
2. 
http://j3h.janrain.com/openid-specs-rendered/openid-authentication_svn-327.html#return_to_verification
3. http://openid.net/svn/listing.php?repname=specificationspath=rev=326sc=1
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


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

2007-05-18 Thread 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

2007-05-18 Thread 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: Final outstanding issues with the OpenID 2.0 Authenticationspecification

2007-05-18 Thread 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: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification

2007-05-18 Thread 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: RFC: Final outstanding issues with the OpenID 2.0 Authentication specification

2007-05-17 Thread 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: Final outstanding issues with the OpenID 2.0 Authenticationspecification

2007-05-17 Thread 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: Final outstanding issues with the OpenID 2.0 Authenticationspecification

2007-05-17 Thread 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: encoding newlines in attribute values

2007-04-19 Thread 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: Label replacing Key

2007-04-07 Thread 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: Moving AX Forward (WAS RE: SREG namespace URI rollback)

2007-04-06 Thread 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: Logout

2007-04-06 Thread 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: Attribute Exchange 1.0 svn revision 295 review

2007-04-06 Thread 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

2007-04-06 Thread 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

2007-04-05 Thread 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


Re: Attribute Exchange pre-draft 5

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


SREG namespace URI rollback

2007-04-02 Thread 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
http://openid.net/sreg/1.0 from
http://openid.net/extensions/sreg/1.1?

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


Re: SREG namespace URI rollback

2007-04-02 Thread 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.0openid.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


Re: Attribute Exchange pre-draft 5

2007-04-02 Thread 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: Attribute Exchange pre-draft 5

2007-04-02 Thread 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: SREG namespace URI rollback

2007-04-02 Thread 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: modulus and generator optional in association requests

2007-03-20 Thread 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: OA2.0d11: Minor nit-pick regarding normalization

2007-02-02 Thread 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

2007-02-02 Thread 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


Proposal: An anti-phishing compromise

2007-02-01 Thread 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?

2007-01-30 Thread 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:

  link rel=openid.server href=http://op.example.com/openid1;
  link rel=openid2.provider href=http://op.example.com/openid2;

vs.
  link rel=openid.server href=http://op.example.com/openid1;
  link rel=openid.provider href=http://op.example.com/openid2;
  link rel=openid.protocol_version href=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

2007-01-26 Thread 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 head 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 link 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

2007-01-22 Thread 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: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11

2007-01-22 Thread 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: HTML-Based Discovery with OP Identifiers

2006-12-28 Thread 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

2006-12-26 Thread 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: Comments on Auth 2.0 - Pre-Draft 11

2006-12-15 Thread 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

2006-12-15 Thread 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=specificationspath=%2Frev=235sc=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: Consistency of negative responses to checkid_immediate requests

2006-12-14 Thread 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


Re: Comments on Auth 2.0 - Pre-Draft 11

2006-12-14 Thread 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


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

2006-12-14 Thread 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: Consistency of negative responses to checkid_immediate requests

2006-12-14 Thread 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


Re: Comments on Auth 2.0 - Pre-Draft 11

2006-12-14 Thread 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=specificationspath=%2Frev=212sc=1

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


Re: Comments on Auth 2.0 - Pre-Draft 11

2006-12-14 Thread 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=specificationspath=%2Frev=201sc=1
 and 
 http://openid.net/svn/listing.php?repname=specificationspath=%2Frev=209sc=1

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


Re: Comments on Auth 2.0 - Pre-Draft 11

2006-12-13 Thread 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: [security] security hole in signature algorithm

2006-11-19 Thread 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=barbaz=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

2006-11-13 Thread 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:
  link rel=openid.server openid2.server href=...

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: Yet Another Delegation Thread

2006-10-26 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: Yet Another Delegation Thread

2006-10-26 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

2006-10-25 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: Yet Another Delegation Thread

2006-10-25 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

2006-10-25 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: Two Identifiers - no caching advantage

2006-10-21 Thread 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


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

2006-10-20 Thread Josh Hoyt
On 10/19/06, Recordon, David [EMAIL PROTECTED] wrote:
 The proposal we came up with was within the spec describing what to do
 if someone were to enter [EMAIL PROTECTED] in a Relying Party's OpenID
 login form.

Here are the past threads that I could find about this issue:

1. http://lists.danga.com/pipermail/yadis/2005-May/000412.html
2. http://lists.danga.com/pipermail/yadis/2005-June/000501.html
3. http://lists.danga.com/pipermail/yadis/2005-July/001113.html
4. http://lists.danga.com/pipermail/yadis/2005-November/001589.html

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


OpenID version 1.2 instead of 2.0 (Re: off topic - how many people use OpenID ?)

2006-10-20 Thread Josh Hoyt
On 10/20/06, Granqvist, Hans [EMAIL PROTECTED] wrote:
 I propose renaming the existing OpenID 2.0 work to be OpenID 1.2.

(moved over to the specs list, since it hasn't had enough traffic lately)

I think it'd be great to put what we have out as OpenID 1.2. That way,
the debate and proposals here can continue, while we can start
implementing the features that we already know we want and are already
specified.

This should be good for the people (like me) who want to get a better
revision out to users and the community as soon as possible. It should
also be good for the people who have changes that they want to make,
since changes could be debated solely on their merits and not on how
late it is in the specification process.

Also, it reserves the number 2.0 for the final version of the protocol wink/

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


Portable Identifier Support Proposal (patch)

2006-10-20 Thread 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=specificationsrev=70sc=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 eref
 target=http://www.oasis-open.org/committees/download.php/15376;
 XRI/eref.  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.
   /t
 
   t hangText=End User:
@@ -154,7 +154,7 @@
 that they own.
   /t
 
-  t hangText=Delegate Identifier:
+  t hangText=IdP-Specific Identifier:
 An alternate Identifier that can be included in the discovery
 response.
   /t
@@ -751,21 +751,17 @@
   /t
 
   t hangText=Claimed Identifier:
-(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.
   /t
 
-  t hangText=Delegate Identifier:
-(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.
+  t hangText=IdP-Specific 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.
   /t
 /list
   /t
@@ -820,8 +816,8 @@
   /t
 
   t
-An lt;openid:Delegategt; tag (optional) whose
-		text content is the Delegate Identifier.
+An lt;openid:Delegategt; tag (optional) whose text
+content is the IdP-Specific Identifier.
   /t
 /list
   /t
@@ -928,7 +924,7 @@
   t
 A lt;LINKgt; 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
   /t
 /list
   /t
@@ -1362,11 +1358,24 @@
 /t
 
 t
+  openid.portable
+  list style='empty'
+t
+  Value: (optional) The Claimed Identifier.
+/t
+t
+  Note: If the portable identifier is not specified,
+  it is assumed to be the same as the IdP-specific
+  identifier.
+/t
+  /list
+/t
+
+t
   openid.identity
   list style='empty'
 t
-  Value: (optional) Delegate Identifier when
-  available, otherwise the Claimed Identifier
+  Value: (optional) The IdP-Specific Identifier.
 /t
 t
   Note: If this is set to the special value
@@ -1574,11 +1583,25 @@
 /t
 
 t
+  openid.portable
+  list style='empty'
+t
+  t
+Value: (optional) The Claimed Identifier
+  /t
+  t
+Note: If this value is absent, it defaults to the
+value of openid.identity.
+  /t
+/t
+  /list
+/t
+
+t
   openid.identity
   list style='empty'
 t
-  Value: (optional) The Identifier about which the IdP
-  is making a positive authentication 

Re: Question: multiple IdPs?

2006-10-19 Thread Josh Hoyt
On 10/18/06, Recordon, David [EMAIL PROTECTED] wrote:
 Yeah, the XML file can be based elsewhere.

It is especially noteworthy that unless users are combining services,
the XRDS document can be the same one that the IdP has issued to go
with the IdP-specific URL.

For instance, if I want to use another URL with my myopenid account, I
just have to add a meta tag pointing to http://josh.myopenid.com/xrds.

This means that for non power-users, it's still just as simple as
adding one tag to the top of the HTML.

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


Re: Two Identifiers - no caching advantage

2006-10-19 Thread Josh Hoyt
On 10/19/06, Josh Hoyt [EMAIL PROTECTED] wrote:
 when she has control

Sorry that I didn't put this all in one message, but:

I think it's worthwhile to be aware of what might happen in scenarios
where your identifier has been stolen, but it should not have much
bearing on which proposal gets accepted, since the attacker will have
been able to inflict much greater harm elsewhere. I doubt that the
protocol can offer much protection if someone actually gets control of
your identifier.

For instance, some RPs will offer a way to transition an account from
one identifier to another (for e.g. domain names expiring). The
attacker can just transition those accounts to an identifier of hers.

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


Re: Question: multiple IdPs?

2006-10-18 Thread Josh Hoyt
On 10/18/06, Dick Hardt [EMAIL PROTECTED] wrote:
 Thanks Drummond, but what if I am using HTML-based discovery? (that
 is what I am going to use in my vanity domain, much easier to implement)

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

HTML discovery is in there solely for compatibility. From the spec:

  If a Relying Party locates an IdP using HTML-based discovery, it
MUST use OpenID
  Authentication 1.1 Compatibility when communicating with that IdP.

This is because you would otherwise not know whether to use OpenID 1
or 2. Yadis has an explicit type, so it's not a problem.

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


Re: Summarizing Where We're At

2006-10-17 Thread Josh Hoyt
On 10/17/06, Dick Hardt [EMAIL PROTECTED] wrote:
   * Authentication Age
- Re-proposed today adding clarity in motivation, general
   consensus is
   needed to add to specification.
  
   -1
 
  There is no reason for this to be in the core. I could make more
  arguments about it, but I'll stop there, unless there is consensus
  that it should go in the core.

 Would you provide a reason to counter my justification:
 http://openid.net/pipermail/specs/2006-October/000433.html

 Your vote is a -1, not a zero, so I would like to understand why.

The way that I understand your argument is it has something to do
with authentication, so put it in the core spec. Features should be
in an extension if it can be, so that the spec is easier to
understand, implement, and extend. Especially if there is not
consensus.

I am also not convinced that it's technically the right way to
accomplish what you're aiming to accomplish, but I am not going there
unless you can convince enough people that the use case is in scope
for core OpenID authentication.

Also:
  http://openid.net/pipermail/specs/2006-October/000206.html

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


Re: Summarizing Where We're At

2006-10-16 Thread Josh Hoyt
Here are my reactions to what's outstanding:

On 10/15/06, Recordon, David [EMAIL PROTECTED] wrote:
 * Request Nonce and Name
  - Has been partially implemented, openid.nonce -
 openid.response_nonce, no agreement on the need of a request nonce
 specifically, rather discussion has evolved into allowing a RP to pass
 appdata like in Yahoo's BBAuth.  No formal proposal on the table yet,
 thus will not be included in this version.

Take no action

 * Authentication Age
  - Re-proposed today adding clarity in motivation, general consensus is
 needed to add to specification.

-1

 * Remove setup_url
  - Little discussion and no general consensus to do so.  Rather seems
 asking for feedback from checkid_immediate implementers on the parameter
 would be beneficial at this time.

+1

 * Consolidated Delegation Proposal
  - Very active discussion, the only proposal I'm willing to stall the
 spec for.  Seems very important a strong conceptual model is created at
 this time.

-0 on status quo (draft 10)
+0 on single-identifier
+1 on two-identifier

 * Change Default session_type
  - Proposed, no discussion yet.

Will address in separate message

 * Bare Request
  - Proposed, no discussion yet.

-0 (YAGNI)

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


Re: Identifier portability: the fundamental issue

2006-10-16 Thread Josh Hoyt
On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
 In this case you are better off opening a separate account with this
 or some other IdP. The current delegation model will not protect you
 at all. The delegate tag is in a publicly accessible Yadis document.

 I agree that anonymity is an important feature, but the current
 solution gives you only a false sense of security.

What's the current solution that you're talking about? As far as I
know, no one is suggesting portable identifiers as a way to achieve
anonymity. I also do not think anyone is suggesting that IdP-driven
identifier selection will make you anonymous *to the IdP.*

You are correct that in order to avoid anyone knowing the identifiers
that you use, you have to have separate accounts on different IdPs. I
can't come up with any way that the protocol can help (or impede!) the
user with achieving this.

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


Re: Notes From Draft 10

2006-10-16 Thread Josh Hoyt
On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
 Sorting of unicode strings while not terrible hard it is not trivial
 either. Why bother? The list of signed fields gives an explicit
 ordering, this is good enough IMO.

Sorting by UTF-8-encoded octet sequence is easy.

 Why would be an alphabetically sorted list better?

Just so that there is an obvious one way to do it, so that it's easier
to get right, if I understand David's motivation. It's also easier to
make clear in the spec.

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


Re: Notes From Draft 10

2006-10-16 Thread Josh Hoyt
On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
  Just so that there is an obvious one way to do it, so that it's easier
  to get right, if I understand David's motivation. It's also easier to
  make clear in the spec.

 If ordering is not important then you are guaranteed to get it right.

But ordering *is* important whether a specific order is prescribed or
not. The same ordering has to be used when the signature is generated
and when it is checked.

 The spec could recommend alphabetical ordering, but I don't see the
 need for a must.

If it's not a MUST, then it doesn't clarify or simplify the procedure,
because it could still be any order.

Again, I don't care very much about making this change. Unless David
stands up for it, I'm going to drop it.

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


Re: Identifier portability: the fundamental issue

2006-10-14 Thread Josh Hoyt
On 10/13/06, Drummond Reed [EMAIL PROTECTED] wrote:
 So whether it's in the spec formally or not, I don't really care.  But the
 spec MUST contain details on the precautions a RP should take.

 Yup.(Got that, editors?)

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

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


Re: Identifier portability: the fundamental issue

2006-10-14 Thread Josh Hoyt
On 10/13/06, Chris Drake [EMAIL PROTECTED] wrote:
 DR CASE 1: the protocol supports only IdP-specific identifiers and no 
 portable
 DR identifiers.

 DR RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1.

 Please explain?  If I've got an OpenID URL (eg: my vanity domain), I
 can transfer this via DNS (or just update my OpenID LINK).  If
 I've got an i-name, I can transfer this too.  Where's the lock in ?

This is true assuming that IdPs have uniform support for registering
an identifier that it did not issue. OpenID 1 addressed this in its
architecture. In OpenID 1, the identifier does not even have to be
registered with the IdP. The proposed changes alter this arrangement.
In the 2-identifier proposal, the IdP does not need to support
registering identifiers, but it can be aware that a third-party
identifier is being used. In the one-identifier proposal, the IdP is
solely responsible for being aware of the arrangement.

I do not think the success of the protocol rides on this decision, but
I think it's important to understand, and understand the implications
of the choice that is made. In many ways, the spirit of OpenID has
been to empower the user above all. OpenID 1's delegation is
consistent with that.

 I do not believe the RP needs to know the IdP-specific identifier ever
 (worse: I think it should never be allowed to know it, or even be
 allowed to see it!).

Why not?

 Yes - we need 2 identifiers - but from the point
 of view of the specs - the OpenID protocol really only needs to deal
 with one.

See above.

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

Where is power being granted to the RP? It has pretty much none. It
*does* have responsibility, but only as much as is necessary to make
the protocol work.

 Can we not adopt my earlier suggestion: just ensure OpenID can permit
 IdP-initiated logins.  This permits every scenario of portability (and
 privacy) that everyone wants, without us having to continue to debate
 it ?

Huh? How is IdP-initiated login related to privacy or portability?

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


Re: RP attack vector - why two identifiers are redundant

2006-10-14 Thread Josh Hoyt
On 10/14/06, Dick Hardt [EMAIL PROTECTED] wrote:
 Since the request is not signed and flows through the user, the IdP
 does not know the request message has not been modified. If the IdP
 assumes the two identifiers are bound, then a malicious user can
 pretend to be a different user from the same IdP to the RP. This
 presumes the IdP is using an IdP identifier and the RP is using an RP
 identifier and the binding is assumed by sending both.

 Therefore, the IdP MUST make sure the two identifiers are linked, so
 sending both is redundant for the IdP.

The relying party knows both identifiers from doing discovery, and it
must check to make sure they match what is in the assertion. Since the
relying party MUST make sure it matches, the IdP doesn't have to. I
would say that the IdP SHOULD check to make sure it's valid, but it's
not strictly required.

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


Re: Consolidated Delegate Proposal

2006-10-13 Thread Josh Hoyt
On 10/13/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
 The IdP is issuing a signed assertion about these identifiers, I
 would assume the IdP to check the link between these identifiers.

Sending two identifiers does not *prevent* the IdP from checking to
make sure they match.

 What if a bad RP sends an auth request with a mismatched set and then
 re-posts the response to some other RP? I am sure someone will figure
 a way to exploit this.

It is, and must be, the relying party's responsibility to ensure that
the information in the response matches what is discovered. This is
true regardless when portable identifiers are used and when they are
not. It is true for all of the proposed delegation mechanisms. It is
really one of the fundamental elements of OpenID.

A response from an IdP is meaningless until it is compared with the
discovered information for the identifier in question.

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


Re: [PROPOSAL] request nonce and name

2006-10-12 Thread Josh Hoyt
On 10/12/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
 If passing through all unrecognized parameters can cause problems
 then there could be a special namespace for this purpose. For
 example, all parameters with names starting with openid.pass. should
 be ignored by the IdP and passed back to the RP.

Yahoo Browser-based authentication [1] has a single parameter called
appdata (that you can find in [2]) that is used for this purpose.
This seems general enough to me.

Josh

1. http://developer.yahoo.com/auth/
2. http://developer.yahoo.com/auth/user.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Delegation discussion summary

2006-10-12 Thread Josh Hoyt
On 10/12/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
 The protocol does not need to touch on IdP-specific identifiers (aka
 delegated identifiers) at all IMO.

If there is a specified mechanism that must be supported for using a
portable identifier, all IdPs will support it, so identifiers will
actually be portable. You'd have a very difficult time trying to get
people here to remove portable identifier support from the OpenID
protocol.

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


Re: Consolidated Delegate Proposal

2006-10-10 Thread Josh Hoyt
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote:
  RP user id is the identifier by which the relying party knows the
  user.
 This is the one that the user gave the RP?

For URL identifiers, it is the supplied identifer, normalized, after
following redirects. In essence, it's the user's chosen identifier.

For XRI identifers, it's the canonical ID (i-number).

  openid.identity is the IdP user id.
 Where did this come from?

When using delegation, it's the delegate value. Otherwise, it's the
same as the RP user id. It is identical to the way that the value for
openid.identity is currently used in OpenID 1 and the current draft
of OpenID 2.

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


Re: Consolidated Delegate Proposal

2006-10-10 Thread Josh Hoyt
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote:
 My proposal was pretty much your proposal with a couple tweaks
 (sorry, I should have listed these to make it clearer)

 - the IdP can return a different identity then the one the RP sent over

I question whether this is something we want to encourage. I think
it's a separate issue from the delegation mechanism. If the user wants
to choose an identifier, he'll use IdP-driven selection instead of
entering an identifier. I don't feel strongly about this, but I do
feel strongly that this should be decoupled from the delegation
discussion.

 - since the delegate is only used by the IdP, the spec can be
 simplified (in fact, this can be out of band of the spec since it is
 a protocol between the user and the IdP, the RP is not involved)

This was exactly my original proposal:
A request for a delegated identifier and a request for a non-delegated
identifier would be the same for the relying party, and the final,
verified identifier would always be included in the request/response.

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


Re: Consolidated Delegate Proposal

2006-10-10 Thread Josh Hoyt
On 10/10/06, Dick Hardt [EMAIL PROTECTED] wrote:
 The IdP cannot trust the RP's discovery. The IdP will have to make
 sure that the IdP is authoritative for the identifier regardless.

The IdP doesn't have to trust the relying party's discovery. The IdP
*can* make sure that it is authoritative for the rp_user_id, but if it
isn't, the login will fail anyway. Only a malicious or broken RP will
make a request with an identifier that does not point to that IdP. A
malicious or broken RP does not need a meaningless assertion in order
to pretend to have authenticated a user.

The relying party is required to validate the assertion by doing
discovery anyway, and there is no case for sending an identifier that
does *not* delegate to that IdP, so why make the IdP do discovery
again?

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


Re: Consolidated Delegate Proposal

2006-10-09 Thread Josh Hoyt
On 10/9/06, Recordon, David [EMAIL PROTECTED] wrote:
 In terms of openid.display, shouldn't the IdP greet the user in whatever
 manner it uses?  Thus if the user has an account on the IdP, the IdP
 should always greet the user in the same manner with it.  Seems like
 both a usability, phishing, and potential XSS issue if the IdP greets
 the user with a string from the RP.

 Am I just missing something there?

The display name is only useful for XRI synonyms. Basically, =foo and
=bar could both be tied to the same i-number. Doing resolution on =foo
and =bar will yield the same canonical id, which means that they
represent one logical entity. Drummond wants the display name to tell
the IdP *which* synonym the user entered at the RP so that the IdP can
present that same synonym in the UI, since the canonical id is both
the IdP user identifier and the RP user identifier, but is not
user-friendly (=!1234.1234.1234.1234)

For URIs, the display name *must* be the same as the RP user
identifier, because there is no other value is verifiable by the IdP.

Does that explanation help?

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


Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

2006-10-06 Thread Josh Hoyt
On 10/6/06, Martin Atkins [EMAIL PROTECTED] wrote:
 * The IdP returns a document naming its authentication endpoint (in the
 URI field) and a special anonymous token as openid:Token. openid:Token
 may be the same as the public identifier from the previous step, but
 this is not required.

Anonymous is not a good thing to call this. What IdP-driven identifier
selection does is let the IdP help the user choose an identifier. In
no way is the response any more anonymous than an identifier that was
typed in by the user.

It is true that one of the motivations for this feature is the great
improvement in the user experience for site-specific identifiers, but
the IdP could just as well return a cross-site identifier for the
user.

Sorry to go on about terminology, but I think it's important for
understanding what's really going on.

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


Delegation Proposal Amendment

2006-10-06 Thread Josh Hoyt
I'd like to amend my proposal for changing the delegation mechanism:

Revised Proposal


As it stands, openid.identity is the identifier by which the IdP
knows the user. There is no parameter by which the RP knows the user.

I propose to add a field called openid.rp_user_id in checkid_* and
id_res that defaults to openid.identity if it is missing. This
field is the identifier by which the relying party knows the user.
This is the identifier on which discovery was performed by the relying
party.

The name openid.rp_user_id is not the best, but it *is* very
specific. Other suggestions welcome.

Benefits


This proposal retains the current behaviour in terms of who is
responsible for discovery and verification. It makes the messages
between the RP and IdP more explicit. It is completely
backwards-compatible. IdP-driven identifier selection can now return a
delegated identifier (if the user wishes to do so).

Drawbacks
=

The IdP now has knowledge of the identifier that the user entered at
the relying party.

Discussion
==

I think there is general agreement that the protocol messages on the
wire can lead to confusing results. I also think that it's easy to get
the relying party implementation wrong because it has to keep track of
state to ensure that the user gets the right identifier. I don't think
that most relying parties will have a problem keeping state, but I
think it's not a good idea to make proper behavior (using the right
identifier) *depend* on the relying party's implementation of state
storage.

This proposal is similar in spirit to Martin's proposal, in that it
acknowledges that delegation is not really a special case. The main
difference is that (a) it is obvious from the protocol messages what
is going on and (b) discovery is entirely unchanged.

Related threads
===

Original proposal:
  http://openid.net/pipermail/specs/2006-September/02.html

Brad's explanation of openid.delegate:
  http://openid.net/pipermail/specs/2006-October/000182.html

Regarding the purpose of delegation:
  http://openid.net/pipermail/specs/2006-October/000170.html

Martin's similar proposal:
  http://openid.net/pipermail/specs/2006-October/000216.html


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


Re: Delegation Proposal Amendment

2006-10-06 Thread Josh Hoyt
On 10/6/06, Granqvist, Hans [EMAIL PROTECTED] wrote:
 Can you propose this in terms of diffs to the current draft so
 it is glaringly obvious what the proposal means?

Sure.

 Also, I think this diffs to current draft can be most useful
 for all proposals as it cuts through the various semantic
 clouds we all have hanging over our heads ;)

Do you mean literal Unix-style diffs or a human-readable set of
changes to section numbers?

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


Re: What is delegation for? (was Re: Wrapping Up Proposals)

2006-10-02 Thread Josh Hoyt
On 10/2/06, Johannes Ernst [EMAIL PROTECTED] wrote:
 It appears to me that OpenID should be able to do the same thing that
 we've been doing in LID: one-way nonces.

This is the way that it's currently written up in the spec. When I
wrote it up I had LID nonces in mind.

The current proposal is to have *two* nonces - one for the request and
one for the response. I bet there are good arguments for being able to
identify both the request and the response individually, but I can't
come up with any. Why do we need a response nonce if there is a
request nonce?

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


Re: One last plea: fix problem with delegate terminology

2006-10-02 Thread Josh Hoyt
On 10/2/06, Drummond Reed [EMAIL PROTECTED] wrote:
 2) In OpenID Authentication 2.0, define a new term to uniformly describe the
 concept of equivalent OpenID identifiers, i.e., identifiers that are both
 controlled by the same real-world authority (end user), and are mapped
 together to give the end-user control over the identifier they present to an
 RP vs. the identifier by which they authenticate to an IdP.

This seems about the same as the trust_root - realm change.

+0 from me.

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


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

2006-09-28 Thread Josh Hoyt
On 9/27/06, Dick Hardt [EMAIL PROTECTED] wrote:
 Additionally, as we have researched what is contained in registration
 forms, this use case does not look like it will be that common. Many
 forms have some site specific data, and I am now thinking that this
 is not a very useful feature.

I'm glad that we're in agreement on this.

 wrt. passthrough data

 Many sites preserve state between forms with hidden values. Given
 that registration on a site will likely ask the user for some site
 specific data, some sites will likely be maintaining state through
 hidden fields, and it will be easier for them to integrate OpenID if
 the RP can send values that it gets back later on. Given this is not
 explicitly in the spec, we can write it up. Would welcome feedback on
 passthrough data.

This model is only necessary for sites that do not support sessions, right?

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


Re: Request for comments: Sorting fields in signature generation - Call for votes

2006-09-27 Thread Josh Hoyt
On 9/27/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
 please keep in mind that we are not asking for some fancy new
 technology or feature, just conformance with a very basic an wide
 spread convention of handling parameters in HTTP/HTML.

As Kevin pointed out, we are not working on the HTTP/HTML form
processing specification. We are working on an authentication
protocol. Restricting the protocol to forbid multiple parameters with
the same name does not break conformance with anything.

I think that we have discussed the majority of the technical issues
regarding multiple parameters with the same name. I could respond to
your individual points, but I don't think that would get us any closer
to agreement.

Can we get +1/-1 on multiple parameters with the same name from people
without @sxip.com or @janrain.com e-mail addresses?

Clearly, we (JanRain) are -1.

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


Re: Request for comments: Sorting fields in signature generation

2006-09-27 Thread Josh Hoyt
On 9/27/06, Johnny Bufu [EMAIL PROTECTED] wrote:
  Huh? I don't see anything in that section about a requirement to echo
  back parameters.

 Not a requirement, but I read the second paragraph as implying they
 can/could be used.

An IdP is not forbidden from echoing back any unknown parameters it
got, but no OpenID implementation has ever done this, to my knowledge.
I expect that unless the specification said otherwise, applications
would ignore unexpected parameters. As far as I can tell, this is
standard behavior on the Web.

 If that weren't so, then why is there the openid. prefix to the
 parameters in some of the messages?

The reason that the parameters have openid. at the beginning is so
that it is clear that they are part of the OpenID protocol message and
not intended to be operated on by the application that is processing
the OpenID request. Basically, to reduce the likelihood of name
collisions with parameters that the application uses.

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


Re: Request for comments: Sorting fields in signature generation

2006-09-26 Thread Josh Hoyt
On 9/26/06, Barry Ferg [EMAIL PROTECTED] wrote:
 The signature generation algorithm specifies that the fields to be
 signed be ordered in byte order form.  It seems to be implied that
 the ordering is based on using the field names as sorting keys

I think the real topic of this discussion is whether or not multiple
parameters with the same name should be allowed by the specification.

I *strongly* prefer tightening the specification by *disallowing*
duplicate parameter names. PHP is one environment in which the
implementation will be problematic, but other common environments
(e.g. Rails) do not easily support this idiom. There is *no deployed
code* that depends on duplicated parameter names, and I'd like to keep
it that way. Keep it simple if possible.

I agree that the language in the specification should be clarified so
that the sort order is fully explicit. I would resolve this issue by
stating that the pairs must be sorted by key.

On another note:

 Pass-through (or echo) parameters and potentially some OpenID
 extension parameters may include fields with multiple values in order
 to communicate arrays of data, etc.

Attribute exchange and other extensions can *easily* be designed not
to require multiple parameters with the same name.

Pass-through parameters are *not part of any OpenID specification.*
Even if they were, I don't think it would be too great of a
restriction to disallow duplicate parameter names.

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


Re: Request for comments: Sorting fields in signature generation

2006-09-26 Thread Josh Hoyt
On 9/26/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
  Pass-through parameters are *not part of any OpenID specification.*

 They are not, but in order to be able to pass them through you have
 to be able to deal with them. Also, you may have to sign them as well.

No one has written a proposal for pass-through arguments and it's not
in any specification, so it's hard to answer your objection. If
someone were to propose adding pass-through parameters to the
specification, I would argue that:

a) Including the pass-through arguments in the OpenID signature is not
necessary (or constructive!)
b) It is quite reasonable to restrict them to only one value per parameter name.

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