Re: [PROPOSAL] Separate Public Identifier from IdP Identifier

2006-10-05 Thread Marius Scurtescu
On 5-Oct-06, at 3:36 PM, Recordon, David wrote:

 Conceptually I think I like this model.  It does seem easier to
 understand.

 Other thoughts on this?

I am still not sure how the delegated identifier is useful. I did  
miss the earlier discussions, so probably I don't have enough  
background on this.

The only problem it seems to solve is that of vanity identifiers.  
Switching IdPs where you had an IdP issued identity for the original  
IdP does not seem to be possible, you have no control over that  
original identity so you cannot use it anymore. If you had a vanity  
identity with the original IdP then switching only means pointing  
your vanity identity to the new IdP. So it really boils down to  
controlling your vanity identity.

Instead of dealing with vanity identities using the delegate tag why  
not let the IdP manage your vanity identities? When you register with  
an IdP you should be able to register additional vanity identities,  
as many as you want. You have to prove to the IdP that you control  
them, but this is a different problem (I'll get back to this).

This is similar to domain names (identities) and hosting companies  
(IdPs). You can configure your domain to point to a different hosting  
company (this is like editing your Yadis document to point to another  
IdP). If you don't care about your own domain then you can get cheap  
or free hosting but at some URL controlled by the hosting company  
(these would be the IdP issued identities).

Most of the sites you deal with are RPs, not IdPs. Also, you would  
trust more your IdP then any RP. The link between multiple vanity  
identifiers will be know only to the IdP, the RPs will not know this.

Now, how would the IdP check that you indeed control a vanity  
identity? First of all, you have to point to that IdP. Second, the  
IdP will check that no one else claimed this vanity identity. So  
unless there is an attempt by someone else to claim the same identity  
the IdP can take your word for it. If it wants to go one step further  
(or if there is a conflict) then the IdP can ask you for more proof  
that you own this identity:
- it can send a verification email associated with the domain of this  
identity (if it is a root domain)
- it can ask you to place a special file under this domain/path
- it can ask you to add special headers in the HTML page of this  
identity
- it can ask you to add a special field into the yadis document (and  
this field could be a replacement for the delegate element)

Does this make sense? What am I missing?

Thanks,
Marius



 --David

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Martin Atkins
 Sent: Wednesday, October 04, 2006 11:34 AM
 To: specs@openid.net
 Subject: [PROPOSAL] Separate Public Identifier from IdP Identifier


 Currently the conceptual model is that each user has a public (that
 is, presented to RPs) identifier, but can optionally create additional
 identifiers which delegate to the real identifier. The delegate
 functionality has several purposes, including:
   * Vanity identifiers on personal domains while letting someone  
 else
 do the hard work in running the IdP.
   * Ability to switch IdPs without losing identity

 However, experience has shown that the above model is often  
 difficult to
 grasp for those new to OpenID. This proposal is really just a set of
 terminology changes and an alternative conceptual model that aim to  
 make
 the delegate functionality easier to understand. It does not change  
 the
 mechanism of delegation at all, though it does change the discovery
 protocol.

 I've placed the full proposal on the OpenID wiki:
  http://www.lifewiki.net/openid/SeparateIdentifierFromIdPToken


 ___
 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


Re: [PROPOSAL] request nonce and name

2006-10-12 Thread Marius Scurtescu
On 12-Oct-06, at 12:10 PM, Recordon, David wrote:
 We thus believe that any state tracking needed by a stateless RP  
 must be maintained as GET parameters within the return_to  
 argument.  In the case of a stateful RP, it can either do the same  
 thing, or store state via other means such as using a session id  
 within a cookie to reference database data.
So basically the query string of the return_to parameter is used to  
implement pass through parameters.

Why not require that unknown parameters be passed through? This way  
the return_url is clean and it can be persisted (for bookmarking for  
example) and there are no size limitations.

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.

Marius

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


Re: Delegation discussion summary

2006-10-12 Thread Marius Scurtescu
On 12-Oct-06, at 10:29 AM, Josh Hoyt wrote:

 Both portable and IdP-specific identifiers
 --

 Include both the portable identifier and the IdP-specific identifier
 in the request and response ([4]_ and
 [5]_)::

   openid.identity = http://my.idp.specific.url/
   openid.portable = http://my.portable.url/

 The relying party is still responsible for checking to make sure that
 the IdP-specific identifier that is returned matches what is
 discovered from the portable identifier, but since it is included in
 the authentication response, it is not necessary for the relying party
 to maintain this state, and an authentication response is meaningful
 without the context of the request.

 The messages in this proposal are very explicit about what is going
 on. The only way in which this differs from OpenID 1 is that the
 portable identifier is also included in the response. The meaning of
 the openid.identity parameter is identical to its meaning in the
 OpenID 1 protocol (the IdP-specific identifier).

Not sure why are both identifiers needed? The RP cares only about the  
portable one, right?

Is backwards compatibility the only reason?



 Portable identifier only
 

This option makes sense to me.

The protocol does not need to touch on IdP-specific identifiers (aka  
delegated identifiers) at all IMO. This is really an IdP  
implementation detail. The only important point seems to be the fact  
that identifiers are portable and IdPs should allow users to move  
them around.


Marius

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


Re: [PROPOSAL] request nonce and name

2006-10-12 Thread Marius Scurtescu
On 12-Oct-06, at 5:07 PM, Josh Hoyt wrote:

 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.

True, even one single pass through parameter should do.

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


RE: Delegation discussion summary

2006-10-13 Thread Marius Scurtescu
On Thu, 2006-12-10 at 22:47 -0700, Drummond Reed wrote:
 +1 to Josh's point. IMHO identifier portability is sacred. If anyone
 disagrees, please post, can we assume we have consensus on this?

Yes, portability is sacred.

I was suggesting that portability can be resolved between the user and
the IdP. I cannot see how the protocol can help this by passing two
identifiers. And if only the portable identifier is passed then there is
no need to mention the IdP-specific identifier.

Marius

 
 =Drummond 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Josh Hoyt
 Sent: Thursday, October 12, 2006 8:56 PM
 To: Marius Scurtescu
 Cc: specs@openid.net
 Subject: Re: Delegation discussion summary
 
 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
 
 

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


Re: Delegation discussion summary

2006-10-13 Thread Marius Scurtescu
On 13-Oct-06, at 12:20 PM, Drummond Reed wrote:

 Marius wrote:

 I was suggesting that portability can be resolved between the user
 and
 the IdP. I cannot see how the protocol can help this by passing two
 identifiers. And if only the portable identifier is passed then
 there is
 no need to mention the IdP-specific identifier.

 Marius, see the analysis at
 http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now
 updated
 to include Josh's lastest thinking from
 http://openid.net/pipermail/specs/2006-October/000357.html.

 In sum, not being able to send the IdP-specific identifier: a)
 forces the
 IdP to redo resolution, which is unnecessary and slows performance,
 and

 Not necessarily. When you register with the IdP most likely you will
 claim all your portable identifiers with this IdP, so the IdP knows
 about them.

 With XRI i-name/i-number infrastructure that's neither practical nor
 desirable. With XRIs, users control their own synonyms, i.e., I can  
 register
 a delegated i-name within a specific community (for example, at
 @example.community I could register @example.community*drummond)  
 and then
 point that at my personal i-name (=drummond.reed) and the IdP for
 =drummond.reed will never know -- and doesn't need to know. I could  
 go to
 any RP and login in as @example.community*drummond, the RP will  
 resolve this
 to =drummond.reed (through the way XRI resolution automatically  
 handles
 reference processing -- let me know if you want more info about  
 this), and
 end out storing the CanonicalID i-number for =drummond.reed (which is
 =!F83.62B1.44F.2813).

I don't see the point if hiding some of your portable identifiers  
(@example.community*drumond) from your IdP and at the same time  
disclose it to all the RPs you deal with.

If you are using a portable identifier and you have an IdP then it  
seems normal to me to trust your IdP to know your portable  
identifier. I would be more nervous about all the RP knowing my IdP  
issued identifier.

What is not practical about registering your portable identifier with  
your IdP?



 b) prevents the protocol from being stateless.

 How? The RP deals only with the portable identifier and this is the
 only thing the IdP sends back. Why do you need state?

 It follows from the above. But this is so important that I'm going  
 to send a
 separate message about it.

I can't see it, sorry.

If the RP is indexing your account based on your i-number then it  
could send your i-number to your IdP for authentication, but it can  
also send your i-name. I don't think it matters. The IdP should know  
both and it can lookup your account with any of them. What state must  
the RP save? The RP has both your i-name and i-number as well (unless  
you are registering), so when the response comes back it can look you  
up with any.

Marius

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


Re: Identifier portability: the fundamental issue

2006-10-13 Thread Marius Scurtescu

On 13-Oct-06, at 12:59 PM, Drummond Reed wrote:

 Yesterday we established consensus that with OpenID, identifier  
 portability
 is sacred.

 Today I'd like to establish consensus on the following postulate:

 To achieve identifier portability in OpenID, it MUST be possible  
 for the RP
 and the IdP to identify the user using two different identifiers: an
 identifier by which the RP knows the user (the portable  
 identifier), and an
 identifier by which the IdP knows the user (the IdP-specific  
 identifier).

 I would submit that if this postulate is true, then OpenID  
 Authentication
 2.0 requires two identifier parameters because if the protocol only  
 allows
 sending one, then:

 1) If the RP sends the IdP-specific identifier, the RP must keep  
 state to
 maintain mapping to the portable identifier (bad), and

I agree with that.


 2) If the RP sends the portable identifier, an IdP is forced to do a
 resolution a second time after the RP has already done resolution  
 (bad).

No, the IdP is not forced to do a resolution. The IdP already knows  
that.


 OTOH, if the postulate is false, then a case can be made for OpenID
 Authentication 2.0 having just one identifier parameter.

 PROOF

 CASE 1: the protocol supports only IdP-specific identifiers and no  
 portable
 identifiers.

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

Agreed.


 CASE 2: the protocol supports only portable identifiers and no IdP- 
 specific
 identifiers.

 RESULT: IdP is forced to know and store all portable identifiers  
 for a user,
 including identifiers for which the IdP is not authoritative, and  
 users

Why would the IdP need to know identifiers over which it is not  
authoritative?


 would be forced to register all their portable identifiers with  
 their IdP,
 and to update these registrations every time the user adds or  
 deletes a
 portable identifier. Highly undesirable if not impossible.

I don't see this as undesirable but as necessary. If I have a  
portable identifier and I configure it to point to some IdP for  
authentication it only makes sense for the IdP to know about the  
identifier as well.

Marius

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


Re: Consolidated Delegate Proposal

2006-10-13 Thread Marius Scurtescu
On 12-Oct-06, at 11:40 PM, Drummond Reed wrote:

 Drummond wrote:
 Since the RP has to do discovery on the i-name, the RP already  
 has the
 i-number (CanonicalID). Further, as explained in previous  
 threads, the
 CanonicalID is the primary key the RP wants to store for the user,
 not the
 i-name, because the i-number is forever while the i-name could  
 change.

 The RP is also motivated to send the i-number to the IdP for the
 same reason
 that the RP is motivated to send the delegate URL (if available): to
 increase performance by saving the IdP from having to re-resolve
 the i-name
 (in the XRI case) or original URL (in the URL case).

 Dick wrote:

 Won't the IdP will still have to resolve the i-name? The IdP can't
 trust the RP, or know that the i-name and i-number are really linked
 unless it checks itself.

 There are no trust issues involved with the IdP using the  
 identifiers sent
 by the RP. The RP is relying on the IdP, not vice versa. If the  
 RP sends
 the wrong identifiers, it's fooling no one but itself. Thus the IdP  
 has no
 reason to re-resolve (and good performance reasons not to).

The IdP is issuing a signed assertion about these identifiers, I  
would assume the IdP to check the link between these identifiers.

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.

Marius

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


Re: Notes From Draft 10

2006-10-16 Thread Marius Scurtescu
On 16-Oct-06, at 2:44 PM, Josh Hoyt wrote:

 On 10/16/06, Recordon, David [EMAIL PROTECTED] wrote:
 6.1 Signed List Algorithm
 [...]
 I'm thinking it would make sense to
 change this algorithm to first alphabetically sort the arguments  
 to make
 it very clear in terms of ordering.

 I think it's a good idea to say that the signed list MUST be generated
 by the IdP in that order. Then signature *verification* is compatible
 with OpenID 1's algorithm. Unless there is objection, I'll do this.

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.

Why would be an alphabetically sorted list better?

Marius

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


Re: Notes From Draft 10

2006-10-16 Thread Marius Scurtescu
On 16-Oct-06, at 3:13 PM, Josh Hoyt wrote:

 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.

This is not the same as alphabetical ordering though.

It could be the same in most cases, and probably it is for the  
current set of defined open id parameter names. For alphabetical  
ordering you have to get into locales and collations.


 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.

If ordering is not important then you are guaranteed to get it right.  
The spec could recommend alphabetical ordering, but I don't see the  
need for a must.

Marius

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


Re: encoding newlines in attribute values

2007-04-19 Thread Marius Scurtescu
On Wed, 2007-18-04 at 23:25 -0700, Douglas Otis wrote:
 On Apr 18, 2007, at 8:31 PM, Marius Scurtescu wrote:
 
  Base64 encoding is a pretty good candidate for binary data, but you
  cannot apply the same encoding to text fields.
 
 RFC4648 URL and Filename safe Base 64 Alphabet might be a good choice.
 
  Applying base64, or similar encoding appropriate for binary data, to
  text fields has two drawbacks:
  - renders the field unreadable
 
 Binary data is often unreadable.

True, but text is readable and ideally it should stay like that.

 
  - increases the size of the field
 
 Base 64 increases the size of the encoded element by about 30%.
 
  URL-encoding has the advantage that probably all web frameworks will
  have functions to encode and decode this format.
 
 URL-encoding increases the size of the encoded element by 300%.

Only unsafe characters are encoded, not the whole string.

Not sure how UTF-8 changes any of this.


Marius


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


Re: encoding newlines in attribute values

2007-04-19 Thread Marius Scurtescu

On 19-Apr-07, at 7:29 AM, Rowan Kerr wrote:

 On 18-Apr-07, at 9:47 PM, Johnny Bufu wrote:
 The core spec doesn't allow newline characters (\n) in any openid.*
 values. Currently, Attribute Exchange doesn't specify a way to encode
 newlines in attribute values.

 Every indirect OpenID message would seem to be already url-encoded by
 the browser, or server as post data .. so \n = %0A (i.e.
 application/x-www-form-urlencoded mime type)

 Do we need a pre-url-encode encoding, or can we rely on browsers to
 do the right thing... I suppose it's helpful to spell it out for non-
 browser agents that want to pass OpenID messages.

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.


 If we want to define sending binary data in OpenID messages, maybe we
 should leverage multipart/form-data.

Same as above, need to encode for signatures to work.

Marius

___
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 Marius Scurtescu
On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote:

 7.3.3. HTML-Based Discovery

 A LINK tag MUST be included with attributes rel set to  
 openid2.provider
 and href set to an OP Endpoint URL

 A LINK tag MAY be included with attributes rel set to  
 openid2.local_id
 and href set to the end user's OP-Local Identifier


 Could somebody please enlighten me as to what's wrong with leaving  
 those as
 openid.server and openid.delegate respectfully (i.e.
 backward-compatible)?

The new attribute values are needed in order to signal an OpenID 2  
provider.

But you bring up a good point, backwards compatibility can be easily  
broken here.

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.

Probably the spec should say this in section 7.3.3 and give clear  
instructions regarding OpenID 1.1 tags.

Marius

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


Re: Final outstanding issues with the OpenID 2.0Authenticationspecification

2007-05-18 Thread Marius Scurtescu
On 18-May-07, at 11:09 AM, Recordon, David wrote:

 Hey Marius,
 Good point, committed a patch so please review! :)
 http://openid.net/svn/diff.php?repname=specificationspath=% 
 2Fauthentica
 tion%2F2.0%2Ftrunk%2Fopenid-authentication.xmlrev=325sc=1

That was fast :-)

Looks good, but I would add to that a sentence stating that you  
SHOULD put both sets of tags when editing HTML pages in order to be  
backwards compatible.

Thanks,
Marius


 Thanks,
 --David

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Marius Scurtescu
 Sent: Friday, May 18, 2007 10:48 AM
 To: Dmitry Shechtman
 Cc: 'OpenID specs list'
 Subject: Re: Final outstanding issues with the OpenID
 2.0Authenticationspecification

 On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote:

 7.3.3. HTML-Based Discovery

 A LINK tag MUST be included with attributes rel set to
 openid2.provider
 and href set to an OP Endpoint URL

 A LINK tag MAY be included with attributes rel set to
 openid2.local_id
 and href set to the end user's OP-Local Identifier


 Could somebody please enlighten me as to what's wrong with leaving
 those as openid.server and openid.delegate respectfully (i.e.
 backward-compatible)?

 The new attribute values are needed in order to signal an OpenID 2
 provider.

 But you bring up a good point, backwards compatibility can be easily
 broken here.

 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.

 Probably the spec should say this in section 7.3.3 and give clear
 instructions regarding OpenID 1.1 tags.

 Marius

 ___
 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 Marius Scurtescu
On 18-May-07, at 11:45 AM, Josh Hoyt wrote:

 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.

Good point.

I'm sure that this will break a few implementations, checking  
openid4java right now...

Thanks,
Marius

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