Re: Questions about IIW Identifier Recycling Table

2007-06-07 Thread Johnny Bufu
Hi David,

The idea was to list as columns the things potentially affected by  
this change and important enough that we cared. In the end we chose  
'URL + public fragment' as the one with the most check marks.

See below my comments; maybe others can correct / fill in the gaps.

On 5-Jun-07, at 1:36 PM, David Fuelling wrote:

 I wasn't at IIW, so please bear with me.

 In reference to the wiki at
 http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling, can  
 somebody
 clarify what some of the terminology means?  Specific questions are  
 below.

 1.) For URL+Fragment, what is the distinction between private and
 public?

 2.) Ditto For URL+Token (I assume this means a public vs. private  
 token?)

Public: the RP presents the full identifier (fragment included) to  
third parties.

Private: the reverse of the above. Not sure if this also covered the  
case (mentioned the day before the meeting) of the OP generating  
custom fragments for each RP.

 3.) What does DE mean in the Does not require change to DE?

Delegation. Corrected the wiki.

 4.) In the Stolen OP account header, it appears that all 4 of the  
 proposed
 methods have problems.  However do we really want an identifier to be
 recycled if an account is stolen ( i.e., what if an account is only  
 stolen
 for a brief period, but then recovered?)

Rather, neither of the for proposed methods help you if your OP  
account is stolen, so this column doesn't make a difference.


 4.) What is Active Recycling?

Not 100% here, but I believe the user / OP can choose when to recycle  
an identifier.


 5.) In the New DB Field header, doesn't an OP/RP need a new DB  
 field in
 the fragment scheme, in order to distinguish between the id and the  
 current
 fragment?  Or does the OP/RP simply store the whole URL (fragment  
 included)
 and parse as necessary?

Corrected this one to One identifier / New DB field as it shows in  
my picture.

The RP can dynamically strip the fragment when it needs to display  
the identifier, and keep it in full (including the fragment) for the  
rest of the cases.

 6a.) What is MO in MO Strip Fragment?

 6b.) What does the MO Strip Fragment header mean in general?

No strip fragment == there is no extra work required for stripping  
the fragment. This is kind of a mirror of the previous column (one  
identifier), but dynamically stripping the fragment was considered  
better than requiring a new DB field for the tokens (so this mirrored  
column pair was regarded slightly in favor of fragments vs tokens).


The lost domain shows as lost domain when owning OP in my  
picture. This was considered less important (and smaller in size on  
the whiteboard). I also don't remember why private fragments/tokens  
don't help here, or why the public token does.


Johnny

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


Re: Questions about IIW Identifier Recycling Table

2007-06-07 Thread David Fuelling

Hey Johnny,

Thanks for your clarifications and answers to my questions about [1].

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

To make Identifier Recycling Happen:
1.) The OP should send the RP a Unique hash value as an attribute in
AttributeExchange.  This unique value should be the hash of :

+ nonce
+ op_secret_password
+ user_supplied_secret_password
+ rp_url.

For example, SHA256[1393k3k3939k + op_recycling_password +
my_recycling_password +  http://example.com; ].

In this scheme, each RP will receive (via Attribute Exchange) a one-way
hashed value that is unique to the OP/RP/OpenId/User combination.  This
value cannot be forged so long as the recycling passwords for the OP and
User are not compromised.  (Note that the user's recycling password should
probably be different from the actual login password).

2.) When an account should be recycled, the OP should force the new user to
supply a new recycling password, which will change the hash received by a
given RP.  This is the signal to the RP to use a different/new account on
the RP side, despite having seen the OpenId before.

3.) This scheme would also protect against an OP domain expiring, and
getting picked up by a malicious new owner.  In this case, the OP recycling
password will not be known/valid, and the the new domain owner won't be able
to make auth assertions for existing RP accounts that were served by the
previous OP owner.

4.) To protect legitimate users from lost recycling passwords, an account
recovery mechanism will need to be in place at a given RP, so that if the RP
thinks the account should be recycled, the end-user has a way to prevent
this (perhaps via email, SMS message, or some other mechanism).  This is a
problem anyway with  the other approaches.

In the end, this approach seems to receive a Check under all of the
headers on the IIW grid

Does not require change to delegation == Check
Lost Domain when owning OP == Check
Active Recycling == Check
Consistent 1.1 == Check (Assuming 1.1 OP/RP's can use AX -- is that true?)
One identifier / New DB Field == Check (all data is stored in the AX
mechanism).
No Strip Fragment == Check
Fragments Can be used by other mechanisms (FOAF, etc) == Check

[1] http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling
[2] http://openid.net/pipermail/specs/2007-May/001767.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


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: Questions about IIW Identifier Recycling Table

2007-06-07 Thread David Fuelling

Hey Josh,

Thanks for your message and great points.  See my thoughts/questions inline.

On 6/7/07, Josh Hoyt  [EMAIL PROTECTED] wrote:


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?



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?

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?).


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.

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(?)


I'm not sure which of these issues were the basis for rejecting this

approach. To me, the biggest problem with it is (2)



I agree that #2 is a problem with the token approach.  However, the fragment
approach doesn't solve the problem of a new OP domain owner being able to
make auth assertions for OpenID's that were created for a previous owner
(See my proposal #3).  This seems to be an edge case, but its effects are
much more devastating than people not being able to visually (or otherwise)
determine who owns a given OpenID.

Maybe the solution is use both approaches at the same time?


Josh


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


The CanonicalID Approach

2007-06-07 Thread Recordon, David
So sitting up here in Seattle with Drummond and we're chatting about the
Canonical ID approach to the identifier recycling and losing
problem.  What I describe below is an example which shows four
identifiers that I use daily, one of them being persistent and that I
know will never be reassigned.

http://daveman692.livejournal.com - reassignable
http://www.livejournal.com/userinfo.bml?userid=1356357 - persistent
http://www.davidrecordon.com - do I want to own it forever?
http://openid.aol.com/daveman692 - reassignable

What I'd like to markup is that my three reassignable identifiers so
that they all use my LiveJournal userid URL as the persistent
identifier.  It should be noted that also marking them as synonyms to
each other follows the same sort of process using the Ref/ tag in my
various XRDS files.

It should also be noted that the identifier you're using as your
persistent identifier must allow you to add references back to your
other identifiers.  While this certainly is a specialized feature, we
envision that OpenID Providers will create a persistence service both
guaranteeing the URL will not be reassigned as well as providing means
to add additional references.  Many of the existing i-brokers already do
this by using OpenID to prove you control the references that you're
adding.  You could also, don't shudder too hard Dick :), use an i-number
as your persistent identifier via this method though on the flip-side
could also use a fragment if that is the approach someone would like to
take.

The nice thing is that this method is extremely flexible in terms of
what you use as your persistent identifier in different cases.  I fully
guarantee I haven't done a great job of explaining all of this, but
hopefully the main point gets across.

--David (and Drummond)

http://daveman692.livejournal.com
XRDS
  XRD
Service
  URIhttp://www.livejournal.com/openid/server.bml/URI
  Typehttp://openid.net/signon/1.0/Type
/Service
 
CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can
onicalID
  /XRD
/XRDS

http://www.davidrecordon.com
XRDS
  XRD
Service
  URIhttps://pip.verisignlabs.com/openid/server/URI
  Typehttp://specs.openid.net/auth/2.0/signon/Type
  LocalIDhttps://recordond.pip.verisignlabs.com/LocalID
/Service
 
CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can
onicalID
  /XRD
/XRDS

http://openid.aol.com/daveman692
XRDS
  XRD
Service
  URIhttps://api.screenname.aol.com/auth/openidServer/URI
  Typehttp://openid.net/signon/1.0/Type
/Service
 
CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can
onicalID
  /XRD
/XRDS

http://www.livejournal.com/userinfo.bml?userid=1356357
XRDS
  XRD
 
CanonicalIDhttp://www.livejournal.com/userinfo.bml?userid=1356357/Can
onicalID
Refhttp://www.davidrecordon.com/Ref
Refhttp://daveman692.livejournal.com/Ref
Refhttp://openid.aol.com/daveman692/Ref
  /XRD
/XRDS
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs