RE: OpenID Provider Authentication Policy Extension

2007-06-22 Thread =drummond.reed
Great work, David. +1 to Han's comments -- they are good points. Coming up
with a better semantic identifier for the phishing-resistant policy isn't
easy but I like his point that it really comes down to the definition that
no shared secret is available to a third party. Perhaps non-shared-secret?
omnidirectional-token?

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Hans Granqvist
Sent: Friday, June 22, 2007 3:50 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: OpenID Provider Authentication Policy Extension

A few comments:

* Would be great if all the namespace URLs resolved into live links.
It always helps in the XML world and probably would in here too.

* Section 4 Defined Authentication Policies

We've talked about this before, but I just want to restate that it is
a bad idea to name a policy based on its inferred values.
Phishing-resistant implies a quality that is not necessarily
measurable. Quality can also shift over time.

The other policies are measurable (you can count number of  factors
used, for example).

I'd strongly advise renaming phishing-resistant to something like
no-secrets-shared (you can probably come up with a more succinct
term)

* 5.2 response params

Requiring openid.pape.auth_policies to have a null value if no
policies were met seems odd (and it may break processing where a value
is always expected by the parser). Better would be to explicitly state
that no policies were met by a predefined literal or URL. For example
openid.pape.auth_policies=http://schemas.openid.net/pape/policies/2007/06/no
ne

* Section 7 Examples

I wanted to see some examples on how PAPE is used in the messages.
Maybe add a few?


I like the work. However, the spec is optional. I was hoping
finalizing auth 2.0 would be top priority.

-Hans

On 6/22/07, Recordon, David [EMAIL PROTECTED] wrote:
 Over the past few weeks I've been working on the OpenID Provider
 Authentication Policy Extension which is designed to replace the work I
 did last year with the Assertion Quality Extension.

 Generally, the goal of this extension is to provide Relying Parties with
 more information about how the End User authenticated to their Provider.
 This is done by a mix of the RP requesting certain policies (such as
 phishing-resistant or multi-factor), the OP helping the End User through
 the authentication process, and then in the OpenID Authentication
 response including the policies that were met as well as optionally a
 strength level for the overall authentication.

 This extension doesn't speak at all toward trust of the End User or
 Provider, so RPs will still have to decide if they believe the
 information returned about the authentication in the response.

 So please, check it out and let me know what you think...especially
 around the questions in the Editorial Comments section at the end.

 http://openid.net/specs/openid-provider-authentication-policy-extension-
 1_0-01.html
 http://openid.net/specs/openid-provider-authentication-policy-extension-
 1_0-01.txt

 Thanks,
 --David
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

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

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


Writeup of XRDS Canonical ID verification for URLs and XRIs

2007-06-13 Thread =drummond.reed
Dick Hardt wrote:

Just to clarify, I do *not* propose we add support for multiple  
identifiers in OpenID 2.0 -- but hope that this discussion sheds  
light that there are other ways of solving the problem besides having  
a permanent directory of identifiers aka the i-names/i-numbers  
mechanisms.

After discussion at IIW, and subsequently on this list last week, the OASIS
XRI TC held a special telecon on Monday to discuss extending XRDS Canonical
ID verification to URLs as well as XRIs. This approach addresses Dick's
issue by enabling verification of any mapping of reassignable to canonical
identifiers (URL-to-URL, URL-to-XRI, XRI-to-URL, XRI-to-XRI). In short, it
would give OpenID users the same choice over their canonical identifier that
they currently have over their claimed identifier.

With the Yadis specification now included in section 4 of XRI Resolution
Working Draft 11 (see
http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris for a copy
of the text of this section -- thanks to David, Johnny, and Rowan for
feedback on the first draft), extending Canonical ID verification to cover
any combination of URLs and XRIs is quite straightforward.

The formal proposal is now fully written up on the XRI TC wiki. The first
link below is to the full page; the second takes you directly to the example
section.

http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification


http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification?action=show#h
ead-a68aa13f6815124db6fbf909f172529e2783ae62 

Feedback actively solicited -- further discussion is planned on the XRI TC
telecon at 10AM Pacific tomorrow morning. If anyone would like to join that
call, just send me email for an invitation.

=Drummond 

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


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

2007-06-05 Thread =drummond.reed

David Recordon wrote:

snip of explanation of problems with fragment solution to OpenID recycling

I don't want to say that I have the answers here, since I don't think I
do.  I do however see the following possible solutions:

1) The core specification only talks about fragments in relation to
Relying Parties, to the extent that they should be stripped from display
though used as a unique key.  We do however need to address how a RP
should handle display and account management differences when a fragment
changes.  I'm guessing it is unreasonable to expect every instance of
https://davidrecordon.com to be replaced with
https://davidrecordon.com/#231hwqai21jb when the fragment changes (not
to mention that the fragment *must* remain private between the OP and RP
to be effective).  An extension is then written describing fragment
usage from the OP perspective with huge warnings about how it should
only be used by large service providers who know what they're doing.

2) We use a centralized canonical id approach like i-numbers.
Basically somebody issues unique and never reassigned ids.

3) We use a distributed canonical id approach.  Providers issue an
ugly non-reassignable URL which points at the pretty one and vice-versa.
Thus https://davidrecordon.com says its canonical is
https://12jbd9210.pip.verisignlabs.com which in turn says it is
https://davidrecordon.com.  We could even kill two birds with one stone
and use link rel='me' / to do this and setup an easy way to create
identifier equality.

4) We use public/private key pairs, though this has the traditional
private key revocation issues.

I think my preference is #3, though I'm sure it has its own issues.

David, first I just want to point out that XRI i-numbers are no more
centralized than DNS, so I don't think there's any difference between #2
and #3 other than #2 uses XRI registries and #3 uses DNS registries.

Second, I agree with you that the better architectural approach to the
OpenID recycling problem is to provide a standard reassignable-to-persistent
synonym mapping capability that will work for both URLs and XRIs (and even
URNs). This solves the problem by allowing *any* reassignable identifier
(either a URL, or an XRI i-name) to be mapped to *any* persistent identifier
(either a persistent URL, an XRI i-number, or even a resolvable URN). 

The fragment solution is in fact just a special case of this architecture,
i.e., it maps a URL-without-a-fragment (reassignable) to
the-same-URL-with-a-fragment (persistent). It does have some special issues
due to the use of URL fragments vs. other components of a URI, but otherwise
it is just one option that could be implemented to map a reassignable to a
persistent identifier.

As Martin has pointed out, the purpose of the CanonicalID element in XRDS is
to support reassignable-to-persistent identifier mapping. Although this is a
native function of XRI resolution (because XRI architecture was explicitly
designed to address the reassignable-to-persistent synonym mapping problem
and thus has explicit syntax for reassignable and persistent identifiers),
there is nothing to prevent CanonicalID mapping from being done with URLs.
Discussion on this thread so far has only entertained using this mechanism
to handle reassignable-URL to persistent-XRI mapping, however there's
nothing to prevent it being used for reassignable-URL to persistent-URL
mapping, or even reassignable-URL to persistent-URN mapping (as long as the
URN is resolveable, such as a Handle ID).

Everything is already in place in XRDS architecture except the Canonical ID
verification rules. The OASIS XRI TC has already published the
reassignable-XRI-to-persistent-XRI Canonical ID verification rules in the
first editor's draft of XRI Resolution 2.0 Working Draft 11 (a more detailed
explanation of those rules will be in the second editor's draft due out
tomorrow). Per Martin's suggestion, in the second editor's draft will also
add the Canonical ID verification rules for
reassignable-URL-to-persistent-XRI mapping.

I see no reason we can't add the rules for
reassignable-URL-to-persistent-URL mapping as well, since it's simply a
matter of the RP confirming that the persistent identifier is also
authoritative for the XRDS.

If we approached it this way, all the OpenID Authentication 2.0 spec would
need to do is specify the use of Canonical ID verification as part of the
OpenID discovery process, and then everyone -- users, OPs, and RPs, would be
able to use any
reassignable-OpenID-identifier-to-persistent-OpenID-identifier mapping
process that worked best for them.

Thoughts?

=Drummond

___
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 =drummond.reed
Josh Hoyt wrote:

The fragment is not secret. It is not protecting your OpenID. You
should be able to get the fragment from any relying party that you
visited. 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).

Isn't this a core flaw with the fragment approach? That if you lose control
of the base identifier, you lose control of any fragment?

Wouldn't it be fairly easy -- precisely because the fragment is not secret
-- for the party that takes over the base identifer to discover the
fragment(s) that have been used earlier, and thus for the new owner to then
be able to spoof any fragment that has been issued?

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?

=Drummond 

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


RE: Generalized solution to OpenID recycling (was RE: The WordPressUser Problem)

2007-06-05 Thread =drummond.reed

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

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

XDI.org is planning to change that policy. Also, effective June 1, the
wholesale annual price of personal i-names is USD $5, and personal i-numbers
is USD $1.

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

If LiveJournal were to suddenly start publishing in the XRDS for 
http://frank.livejournal.com/ that the CanonicalID were 
http://www.livejournal.com/u/3449 (for example) frank would lose his 
account on any site he had already been using.

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

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

I agree that migration of RPs is necessary (it seems necessary for any
solution to the OpenID recycling issue), but is order really a problem?
Isn't it just the following sequence of migration steps:

1) RP today uses only Table #1 of reassignable OpenID identifiers (and so is
vulnerable to OpenID recycling issue).

2) When RP upgrades to OpenID libraries supporting mapping to Canonical IDs,
RP creates Table #2 (Canonical ID table) to go alongside current Table #1
(reassignable OpenID identifier table).

3) Until an RP discovers a Canonical ID for an OpenID user, RP continues to
use Table #1.

4) As RP discovers Canonical ID value for an OpenID user, RP starts
populating Table #2, now protecting each user in Table #2 from OpenID
recycling problem.

The result would be a smooth migration of the RP from supporting only
reassignable OpenIDs to supporting Canonical IDs. Note that this two-table
approach is documented on the dev.inames.net site at:

http://dev.inames.net/wiki/Tech_FAQs#What_are_the_recommended_modifications_
OpenID_Relying_Parties_.28RPs.29_should_make_to_their_user_tables.3F 

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

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

Agreed. But I'm with you that these broader semantics are well worth it
because, as pointed out earlier, the fragment approach only works in the
limited set of cases where you can trust the identifier authority issuing
the fragment never to reassign it. The Canonical ID mapping approach works
for all combinations of persistent and reassignable identifiers, i.e., the
user has their choice of both.

=Drummond

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

2007-06-05 Thread =drummond.reed
David, just want to reinforce that the CanonicalID element in XRDS has
always been defined as containing anyURI, so it's been there to support
mapping of any reassignable identifier to any persistent identifier (or,
technically, any canonical identifier, even if not persistent, though
persistence is the main use case for it).

I'm happy to help with the writeup -- I've already spent a not-insignificant
portion of my lifespan dealing with this issue ;-)

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Recordon, David
Sent: Tuesday, June 05, 2007 3:50 PM
To: Johnny Bufu
Cc: OpenID specs list
Subject: RE: The WordPress User Problem (WAS: RE: Specifying
identifierrecycling)

At that point I'd be concerned as to solving the big OP issue while
not solving the lost domain issue when some of the proposals could
possible solve both.  This largely focuses around using an XRI-style
canonical id, whether that be an i-number or just another ugly URL
which points back at the pretty one.  I know I need to write this up
more...

--David

-Original Message-
From: Johnny Bufu [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 05, 2007 3:18 PM
To: Recordon, David
Cc: Josh Hoyt; Johannes Ernst; OpenID specs list
Subject: Re: The WordPress User Problem (WAS: RE: Specifying
identifier recycling)

On 5-Jun-07, at 11:58 AM, Josh Hoyt wrote:
 The relying parties SHOULD make the fragment available to software 
 agents, at least, so that it's possible to compare identifiers across 
 sites. If the fragment is never available, then there is confusion 
 about which user of an identifier is responsible for content that has 
 been posted. One use case where software agents having access to the 
 fragment is particularly important is if the identifier is used for 
 access control, and the access control list is retrieved from off-site

 (e.g. from a social networking site).

 The implementation that seems most sane is for places that display the

 identifier for human reading look like:

 a href=http://josh.example.com/#this-is-intended-for-machine-
 consumption
  http://josh.example.com//a

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

On 5-Jun-07, at 2:55 PM, Recordon, David wrote:

 I thought the fragment was to be secret so that for the case of using 
 a personal domain you don't have to own joshhoyt.com forever.  Rather 
 as long as your fragments are secret, someone else can buy 
 joshhoyt.com and not be you.  If this is no longer a requirement then 
 it certainly changes the game, though also doesn't solve one of the 
 other aspects of identifier recycling.

I thought so too, but I believe Josh is right - the lost domain  
cell with an X in it (for URL + public fragment) supports Josh's
statement:
http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling

So if we're not dealing with this use case, it becomes actually simpler
to address just the identifier recycling for big OPs, where loosing the
domain is not an issue.


Johnny

___
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: Specifying identifier recycling

2007-06-05 Thread =drummond.reed
For posterity, here's how I'd summarize this thread about using public keys
as persistent identifiers:

1) Yes, a public key could be used as an identifier, and could serve as a
persistent identifier if it was not reassignable.

2) The issue of it becoming invalid as a credential if the private key was
compromised is orthogonal to its use purely as an identifier, i.e., as
Johannes points out, if the private key was compromised, use of the public
key could revert to the role of serving purely as an identifier, and another
set of credentials (such as another public/private key pair) could be
assigned.

3) In this light, the primary drawbacks I see to public keys as identifiers
are:

a) They are typically much larger than other persistent identifiers
designed for this purpose (e.g., XRI i-numbers as issued by XDI.org or
Handles as issued by CNRI).
b) I am not aware of a resolution protocol designed for them, with
the exception that I believe syntactially they could be used as XRI
i-numbers.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Johannes Ernst
Sent: Tuesday, June 05, 2007 7:27 PM
To: =nat
Cc: 'OpenID specs list'
Subject: Re: Specifying identifier recycling

I think you are making an invalid analogy. What prevents you from  
setting up a private key reset function the same way you set up a  
password reset function, using an alternate credential? You allow  
for this for non-public-key credentials but not for others ...

But I don't want to perpetuate this thread given the general  
reluctance of the community to think about public key cryptography at  
this time ... I just want to go on record that I find the arguments  
made counter public keys on this thread non-persuasive and want to  
pick it back up when the community is ready to go there ... (note  
also that the security industry would not exist in the shape it does  
if we didn't have public key crypto, so that technology does  
contribute something somewhere ... perhaps also to OpenID?)

Just follow the following argument ... let's assume that the problem  
that started this thread
... can be solved by adding a number to the URL identifier (using a  
fragment syntax or an i-number or whatever other approaches were  
discussed)
... then it also can be solved by adding a large number instead of  
just any number
... then it also can be solved by adding a large number that could be  
a public key, which is nothing but a large number
... which, therefore, makes a public-key-based approach at least as  
powerful as a plain number

Just some stuff for thought ... ;-)

Cheers,



Johannes.


On Jun 5, 2007, at 17:58, =nat wrote:

 Hi.

 Ok. Now I see the heart of the topic :-)

 Fundamental difference is that you postulate that one cannot lose  
 one's
 credential including all the information that bears onto establish  
 one's
 identity while I do not postulate so.

 For example, one can loose one's password and reset it.
 You can loose your credit card and replace it.
 Doing so has not nullished your identity. You still are yourself.
 Your identity itself and the attribute associated with it apart  
 from this
 particular lost credential data (whether it was a password or  
 credit card)
 stays intact.

 This picture changes dramatically when you use public key
 as your main identity address. If you lose your private key,
 that's the end of story. Your relationships with all the RPs are  
 ruined.

 That is why I believe that we should not be using this kind of  
 public key
 as the identification data for RPs.

 Also, mandating OPs to specify a unique opaque string as the
 identification data would be much simpler than requiring parties to
 do public key verification, I think :-)

 Having said that, I do agree that we should be completing 2.0 cycle
 quickly and making it SIMPLE!

 Nat


 -Original Message-
 From: Johannes Ernst [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, June 05, 2007 1:45 PM
 To: =nat
 Cc: 'OpenID specs list'
 Subject: Re: Specifying identifier recycling

 I would postulate that if you want to be able to prove your
 identity, you cannot allow your credential to be lost,
 interpreting credential to be all the information that
 bears onto establishing your identity. (saying it this way,
 it is a tautology.)

 This is independent of whether anybody uses public keys, or
 any other technology. So I very strongly suspect that while
 it may be more apparent to you guys that the issue exists for
 public key technology, it also exists for all other
 approaches, whether we know them at this time or not!

 However, I can readily see that strong voices (that'd be you
 guys ;-)) are not ready to adopt any kind of public key
 technology into the OpenID family, never mind whether X or Y
 wins this particular argument. So we don't need to continue
 this thread.

 I continue to believe, however, as I have said before, that
 we don't have enough of an agreement on the