Nabble - OpenID - Specs

Re: Reputation

2009-11-18T16:57:04Z

Very interesting!

I've fleshed out some more details on the wiki page:

https://activitystreams.pbworks.com/Stats

Please add more attributes as you think of them!

Chris

On Tue, Nov 17, 2009 at 6:48 PM, Allen Tom <atom@...> wrote:

On a closely related note, many sites have asked us to add "sign up date" as well as other reputation attributes to our OpenID service, mostly for anti-abuse purposes. This would be a useful AX attribute, especially if OPs are willing to standardize on this.

Allen

Chris Messina wrote:
On Tue, Nov 17, 2009 at 4:59 PM, Christian Crumlish <xian@...> wrote:

it almost seems like its own namespace

-x-

p.s.: see also http://developer.yahoo.com/ypatterns/social/people/reputation/

Well, I think what Monica is talking about are more like "stats" than reputation.

Not all services count such things, but many could provide an aggregate count as to the number of friends or contacts someone has, or the number of fans or followers they've accrued. Twitter, Facebook, or Amazon might also provide the number of lists they've made (for Amazon, it'd be wishlists), or other stats.

I wouldn't call this "reputation" because of the weight (and near impossibility) of the subject matter — especially when applying it to two disjoint social contexts.

I think this at least bears inspection as Twitter is providing this information. For now, I've created a page on the wiki to explore this topic further:

https://activitystreams.pbworks.com/Stats

Chris

--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is: [ ] shareable [X] ask first [ ] private

--
You received this message because you are subscribed to the Google Groups "PortableContacts" group.
To post to this group, send email to portablecontacts@....
For more options, visit this group at http://groups.google.com/group/portablecontacts?hl=.

--
You received this message because you are subscribed to the Google Groups "PortableContacts" group.
To post to this group, send email to portablecontacts@....
For more options, visit this group at http://groups.google.com/group/portablecontacts?hl=.

--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is: [ ] shareable [X] ask first [ ] private

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [OpenID board] OpenID v.Next session notes from IIW

2009-11-18T02:18:11Z

This is great stuff. Nice to see clear and reasonable objectives.

I hope we can see an action plan with target date (in six months), milestones, and individual (or group) responsibilities, and hope we can follow the progress till completion.

Best wishes to all the people involved.

On Wed, Nov 18, 2009 at 3:30 PM, Mike Jones <Michael.Jones@...> wrote:

I’ve posted notes on the consensus goals for OpenID v.Next arrived at during the session at IIW at http://self-issued.info/?p=256.

Cheers,

-- Mike

_______________________________________________
board mailing list
board@...
http://lists.openid.net/mailman/listinfo/openid-board

--
http://hi.im/santosh

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Santosh Rajan http://santrajan.blogspot.com

OpenID v.Next session notes from IIW

2009-11-18T02:00:45Z

I’ve posted notes on the consensus goals for OpenID v.Next arrived at during the session at IIW at http://self-issued.info/?p=256.

Cheers,

-- Mike

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Reputation

2009-11-17T20:54:34Z

+1 to stats. And especially to life-of-account, as this is expensive
to game without a time machine.

Note that even with minimal context, it is possible to do useful
statistical analysis and classification based on these types of
features.

On Tuesday, November 17, 2009, Allen Tom <atom@...> wrote:

>
>
>
>
>
>
> On a closely related note, many sites have asked us to add "sign up
> date" as well as other reputation attributes to our OpenID service,
> mostly for anti-abuse purposes. This would be a useful AX attribute,
> especially if OPs are willing to standardize on this.
>
> Allen
>
> Chris Messina wrote:
> On Tue, Nov 17, 2009 at 4:59 PM, Christian Crumlish <xian@...>
> wrote:
>
>
>
>
>
>
>
>
>
>
> it almost seems like its own namespace
>
>
> -x-
>
>
> p.s.: see also http://developer.yahoo.com/ypatterns/social/people/reputation/
>
>
>
>
>
>
>
>
> Well, I think what Monica is talking about are more like "stats"
> than reputation.
>
>
> Not all services count such things, but many could provide an
> aggregate count as to the number of friends or contacts someone has, or
> the number of fans or followers they've accrued. Twitter, Facebook, or
> Amazon might also provide the number of lists they've made (for Amazon,
> it'd be wishlists), or other stats.
>
>
> I wouldn't call this "reputation" because of the weight (and
> near impossibility) of the subject matter — especially when applying it
> to two disjoint social contexts.
>
>
> I think this at least bears inspection as Twitter is providing
> this information. For now, I've created a page on the wiki to explore
> this topic further:
>
>
> https://activitystreams.pbworks.com/Stats
>
>
> Chris
>
> --
> Chris Messina
> Open Web Advocate
>
> Personal: http://factoryjoe.com
> Follow me on Twitter: http://twitter.com/chrismessina
>
> Citizen Agency: http://citizenagency.com
> Diso Project: http://diso-project.org
> OpenID Foundation: http://openid.net
>
> This email is: [ ] shareable [X] ask first [ ] private
> --
> You received this message because you are subscribed to the Google
> Groups "PortableContacts" group.
> To post to this group, send email to portablecontacts@....
> For more options, visit this group at
> http://groups.google.com/group/portablecontacts?hl=.
>
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "PortableContacts" group.
> To post to this group, send email to portablecontacts@....
> For more options, visit this group at http://groups.google.com/group/portablecontacts?hl=.
>

--
--
John Panzer / Google
jpanzer@... / abstractioneer.org / @jpanzer
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Reputation

2009-11-17T18:48:37Z

On a closely related note, many sites have asked us to add "sign up date" as well as other reputation attributes to our OpenID service, mostly for anti-abuse purposes. This would be a useful AX attribute, especially if OPs are willing to standardize on this.

Allen

Chris Messina wrote:

On Tue, Nov 17, 2009 at 4:59 PM, Christian Crumlish <xian@...> wrote:

it almost seems like its own namespace

-x-

p.s.: see also http://developer.yahoo.com/ypatterns/social/people/reputation/

Well, I think what Monica is talking about are more like "stats" than reputation.

Not all services count such things, but many could provide an aggregate count as to the number of friends or contacts someone has, or the number of fans or followers they've accrued. Twitter, Facebook, or Amazon might also provide the number of lists they've made (for Amazon, it'd be wishlists), or other stats.

I wouldn't call this "reputation" because of the weight (and near impossibility) of the subject matter — especially when applying it to two disjoint social contexts.

I think this at least bears inspection as Twitter is providing this information. For now, I've created a page on the wiki to explore this topic further:

https://activitystreams.pbworks.com/Stats

Chris

--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is: [ ] shareable [X] ask first [ ] private

--
You received this message because you are subscribed to the Google Groups "PortableContacts" group.
To post to this group, send email to portablecontacts@....
For more options, visit this group at http://groups.google.com/group/portablecontacts?hl=.

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

OpenID selector demo screen shots

2009-11-16T03:24:20Z

I’ve posted a set of screen captures and commentary corresponding to the OpenID selector demos we gave at the OpenID Summit and the Internet Identity Workshop at http://self-issued.info/?p=235.

-- Mike

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: OpenID 2.1: timed priv. assoc. assertions

2009-10-31T02:58:00Z

My blunder. I wonder whatever I was thinking... Must be too tired...

Thanks for pointing out.

=nat

On Tue, Oct 27, 2009 at 12:05 AM, John Bradley <john.bradley@...> wrote:

Nat you are referring to the assertion lifetimes for a enterprise LAN environment.

For a environment where the RP is not part of the same domain as the IdP.
Level 1: 5min
Level 2: 5min
Level 3: 5min
Level 4: MUST NOT use bearer tokens. (Rules out openID)

The Nonce contains a time stamp that should be used for this.
Clock synchronization can become an issue with times this small. NNTP please.

We could add a TTL to the assertion however it may be as easy to say that OP keep private assertions for a minimum of 5 min.

Andrew's app should refresh any unsolicited positive assertions older than 5 min.

It is interesting that JS can cache assertions like this.

It perhaps also points out the possibility of people using this technique for cross site scripting to sites that a user thinks they are logged out of.

John B.
On 2009-10-26, at 3:40 AM, Nat Sakimura wrote:
I fully agree on this.

It is required not only from AJAX scenario, but also from Assurance Level discussions.

For example, in SP800-63rev.1, Level 1 assertion must expire in 12 hours, Level 3 assertion in 30 min,
and in IDABC Authentication Policy,

Level 1: 24 hours,
Level 2: 12 hours
Level 3: 2 hours
Level 4: Immediate (whatever it means...)

Regards,

=nat

Andrew Arnott wrote:
With the recent OpenID AJAX work I've been doing (blog commenting and popup login) I've run across a problem that while small now, may grow as OpenID popularity increases and AJAX use becomes more mainstream.

When an OP sends a positive assertion signed with a private association, the RP currently has no idea how long this assertion is valid. The OP has their own policy regarding how long before it expires the assertion based on the response_nonce' timestamp. Some OPs may reason "well, it should only take a few seconds for an RP to get back to us to verify this, so any nonce more than 30 seconds old is expired" in order to keep the used nonce bin from filling up too fast.

Here's the problem: at least with my own AJAX designs, the positive assertion the user agent obtains from the OP is not forwarded immediately to the RP. Several assertions are gathered, and the user picks which one to log into the RP with, and to help protect the user's privacy, it's not ideal to send all assertions to the RP or else it's easy for the RP to tie several identities together without the user's consent. If the login screen is left open for several minutes, these assertions can get stale. Particularly in the blog commenting scenario where the user my acquire the positive assertion before writing his blog comment and thereby could wait 15 minutes or more before posting his comment.

So far, I'm mitigating this at the RP by choosing a "reasonable" maximum lifetime for the assertion and the javascript automatically renews the positive assertion after the assertion is assumed to have expired. But since this guess at the assertion's lifetime is not correct for an arbitrary OP, it would be great if with the positive assertion signed with a private association the OP could indicate with another parameter how long the assertion is valid for so the RP javascript code can renew at the optimal interval.

What do you think?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
  
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [OpenID] Content-Type for Key-Value Form response from OP

2009-10-30T21:47:18Z

I don't know how to make editorial changes to the spec. So here's the thread from a year or so ago, suggesting that OP responses containing Key-Value Form encoding include a content-type header of application/x-openid-kvf rather than text/plain or whatever else OPs might arbitrarily choose.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

On Fri, Jun 13, 2008 at 5:48 PM, Peter Williams <pwilliams@...> wrote:

Make an editorial change to a spec, and submit for formal consideration to the spec list. Need be only 2 lines long, and the std iana declaration. Nobody recalls emails.

________________________________
From: Andrew Arnott <andrewarnott@...>
Sent: Friday, June 13, 2008 5:45 PM

To: OpenID List <general@...>

Subject: Re: [OpenID] Content-Type for Key-Value Form response from OP

Unless I hear any objection then, I'm going to code up my library to respond with application/x-openid-kvf as the content-type for Key-Value Form encoded messages.

Thanks for the help coming up with this, Martin.

Andrew Arnott

On Wed, Jun 11, 2008 at 4:59 PM, Andrew Arnott <andrewarnott@...<mailto:andrewarnott@...>> wrote:
(Forwarding to entire list since I hit Reply instead of Reply All).

Thanks, Martin. It sounds like application/x-kvf is better than text/kvf then. Perhaps we can also be more descriptive then as say "application/x-openid-kvf"?

Andrew Arnott

On Wed, Jun 11, 2008 at 1:48 PM, Martin Atkins <mart@...<mailto:mart@...>> wrote:
Andrew Arnott wrote:
> In that case, I move that we adopt text/kvf as the official Content-Type
> for Key-Value Form encoding response messages.
>

Hi Andrew,

Sorry I didn't see your messages until now.

I believe the convention for unregistered MIME types is to prefix the
subtype part with "x-", giving something like text/x-kvf.

However, since the spec mandates UTF-8 for this message format, it may
be more appropriate to use an "application/" type; text types generally
support a "charset" attribute allowing the content to be in an arbitrary
character encoding, which is not appropriate here.

_______________________________________________
general mailing list

general@...<mailto:general@...>

http://openid.net/mailman/listinfo/general

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: OpenID 2.1: timed priv. assoc. assertions

2009-10-30T07:56:37Z

Sure, Allen.

Scenario 1

You know the http://openidux.dotnetopenauth.net/ prototype's selector? Well, all of those OP buttons simultaneously use checkid_immediate to try to obtain a positive assertion. As you know, any OPs that have previously asserted the user's identity at this RP (with "Remember me" checked at the OP) will succeed if the user is logged into the OP. As each OP button on the selector succeeds at obtaining a positive assertion, it displays a green checkmark to the user, suggesting to him that this button was one he picked previously, and can now log in immediately (without any further interaction with his OP). Not only does this optimize the login experience for the user, it helps the user avoid splintering his identity by picking 1 OP the first time, and a different OP the second time by accident.

Also, since this prototype web site gives the user the ability to bind multiple authentication tokens to the same account, perhaps both Yahoo and Google's OP buttons will get a green checkmark on the selector, and either one is the correct choice for the user since both will take the user to the same account. In this instance, it's particularly optimal for the user, who may not be logged into both Google and Yahoo, but only one. The user doesn't care which OP really does the authenticating this time -- but would like to use whichever one he happens to be logged into, and he might not remember which OP he's logged into. These green checkmarks say "Hey, if you click me, you're guaranteed to be logged in immediately without additional interaction with your OP."

Now the point is, when these positive assertions are obtained and the green checkmark displayed, the positive assertion still has not been sent to the RP (it's web server). It's held in a Javascript dictionary of discovery results and assertions on the browser. Why aren't these positive assertions just sent to the RP immediately so it's a non-issue? Two big reasons:

Privacy for the user, particularly where the user is using different OPs at the same RP to manage different accounts at the RP instead of the same account. This prevents correlating of multiple identifiers at the same RP where the user doesn't ask for it.
If the RP verifies these assertions right away, it still must postpone logging the user into the RP until the user chooses which one to use to log in. The RP must then, since it already invalidated the assertion by verifying it, cross-sign the assertion, send it back to the browser, and wait for one of those assertions to come back, then re-verify the assertion using that proprietary cross-signing mechanism. Yech on several levels.

Scenario 2

The blog commenting scenario, where the user never actually logs in, but writes his OpenID Identifier and a long comment, during which time the positive assertion previously obtained expires. The RP doesn't want to maintain state for these... it simply wants to receive the assertion with the comment and thus be able to verify and process the comment in one step.

Now that all said, I so far have implemented John's suggestion of considering 5 minutes the maximum lifetime of a positive assertion and just renewing at that interval. It seems to work well. If you go to my prototype right now, open up the selector and see a green check mark, and wait exactly five minutes, you'll see the checkmark disappear momentarily and then reappear as that assertion is refreshed.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

On Thu, Oct 29, 2009 at 9:44 PM, Allen Tom <atom@...> wrote:

Andrew Arnott wrote:

Here's the problem: at least with my own AJAX designs, the positive assertion the user agent obtains from the OP is not forwarded immediately to the RP. Several assertions are gathered, and the user picks which one to log into the RP with,

Can you describe the use case in more detail? The RP has multiple assertions from different OPs for the same user?

Allen

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: OpenID 2.1: timed priv. assoc. assertions

2009-10-29T21:44:33Z

Andrew Arnott wrote:

Here's the problem: at least with my own AJAX designs, the positive assertion the user agent obtains from the OP is not forwarded immediately to the RP. Several assertions are gathered, and the user picks which one to log into the RP with,

Can you describe the use case in more detail? The RP has multiple assertions from different OPs for the same user?

Allen

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: OpenID 2.1: timed priv. assoc. assertions

2009-10-26T08:05:59Z

Nat you are referring to the assertion lifetimes for a enterprise LAN environment.

For a environment where the RP is not part of the same domain as the IdP.

Level 1: 5min

Level 2: 5min

Level 3: 5min

Level 4: MUST NOT use bearer tokens. (Rules out openID)

The Nonce contains a time stamp that should be used for this.

Clock synchronization can become an issue with times this small. NNTP please.

We could add a TTL to the assertion however it may be as easy to say that OP keep private assertions for a minimum of 5 min.

Andrew's app should refresh any unsolicited positive assertions older than 5 min.

It is interesting that JS can cache assertions like this.

It perhaps also points out the possibility of people using this technique for cross site scripting to sites that a user thinks they are logged out of.

John B.

On 2009-10-26, at 3:40 AM, Nat Sakimura wrote:

I fully agree on this.

It is required not only from AJAX scenario, but also from Assurance Level discussions.

For example, in SP800-63rev.1, Level 1 assertion must expire in 12 hours, Level 3 assertion in 30 min,
and in IDABC Authentication Policy,

Level 1: 24 hours,
Level 2: 12 hours
Level 3: 2 hours
Level 4: Immediate (whatever it means...)

Regards,

=nat

Andrew Arnott wrote:
With the recent OpenID AJAX work I've been doing (blog commenting and popup login) I've run across a problem that while small now, may grow as OpenID popularity increases and AJAX use becomes more mainstream.

When an OP sends a positive assertion signed with a private association, the RP currently has no idea how long this assertion is valid. The OP has their own policy regarding how long before it expires the assertion based on the response_nonce' timestamp. Some OPs may reason "well, it should only take a few seconds for an RP to get back to us to verify this, so any nonce more than 30 seconds old is expired" in order to keep the used nonce bin from filling up too fast.

Here's the problem: at least with my own AJAX designs, the positive assertion the user agent obtains from the OP is not forwarded immediately to the RP. Several assertions are gathered, and the user picks which one to log into the RP with, and to help protect the user's privacy, it's not ideal to send all assertions to the RP or else it's easy for the RP to tie several identities together without the user's consent. If the login screen is left open for several minutes, these assertions can get stale. Particularly in the blog commenting scenario where the user my acquire the positive assertion before writing his blog comment and thereby could wait 15 minutes or more before posting his comment.

So far, I'm mitigating this at the RP by choosing a "reasonable" maximum lifetime for the assertion and the javascript automatically renews the positive assertion after the assertion is assumed to have expired. But since this guess at the assertion's lifetime is not correct for an arbitrary OP, it would be great if with the positive assertion signed with a private association the OP could indicate with another parameter how long the assertion is valid for so the RP javascript code can renew at the optimal interval.

What do you think?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
  
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

smime.p7s (3K) Download Attachment

Re: OpenID 2.1: timed priv. assoc. assertions

2009-10-25T23:40:49Z

I fully agree on this.

It is required not only from AJAX scenario, but also from Assurance Level discussions.

For example, in SP800-63rev.1, Level 1 assertion must expire in 12 hours, Level 3 assertion in 30 min,
and in IDABC Authentication Policy,

Level 1: 24 hours,
Level 2: 12 hours
Level 3: 2 hours
Level 4: Immediate (whatever it means...)

Regards,

=nat

Andrew Arnott wrote:

With the recent OpenID AJAX work I've been doing (blog commenting and popup login) I've run across a problem that while small now, may grow as OpenID popularity increases and AJAX use becomes more mainstream.

When an OP sends a positive assertion signed with a private association, the RP currently has no idea how long this assertion is valid. The OP has their own policy regarding how long before it expires the assertion based on the response_nonce' timestamp. Some OPs may reason "well, it should only take a few seconds for an RP to get back to us to verify this, so any nonce more than 30 seconds old is expired" in order to keep the used nonce bin from filling up too fast.

Here's the problem: at least with my own AJAX designs, the positive assertion the user agent obtains from the OP is not forwarded immediately to the RP. Several assertions are gathered, and the user picks which one to log into the RP with, and to help protect the user's privacy, it's not ideal to send all assertions to the RP or else it's easy for the RP to tie several identities together without the user's consent. If the login screen is left open for several minutes, these assertions can get stale. Particularly in the blog commenting scenario where the user my acquire the positive assertion before writing his blog comment and thereby could wait 15 minutes or more before posting his comment.

So far, I'm mitigating this at the RP by choosing a "reasonable" maximum lifetime for the assertion and the javascript automatically renews the positive assertion after the assertion is assumed to have expired. But since this guess at the assertion's lifetime is not correct for an arbitrary OP, it would be great if with the positive assertion signed with a private association the OP could indicate with another parameter how long the assertion is valid for so the RP javascript code can renew at the optimal interval.

What do you think?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
  

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

OpenID 2.1: timed priv. assoc. assertions

2009-10-25T17:04:36Z

With the recent OpenID AJAX work I've been doing (blog commenting and popup login) I've run across a problem that while small now, may grow as OpenID popularity increases and AJAX use becomes more mainstream.

When an OP sends a positive assertion signed with a private association, the RP currently has no idea how long this assertion is valid. The OP has their own policy regarding how long before it expires the assertion based on the response_nonce' timestamp. Some OPs may reason "well, it should only take a few seconds for an RP to get back to us to verify this, so any nonce more than 30 seconds old is expired" in order to keep the used nonce bin from filling up too fast.

Here's the problem: at least with my own AJAX designs, the positive assertion the user agent obtains from the OP is not forwarded immediately to the RP. Several assertions are gathered, and the user picks which one to log into the RP with, and to help protect the user's privacy, it's not ideal to send all assertions to the RP or else it's easy for the RP to tie several identities together without the user's consent. If the login screen is left open for several minutes, these assertions can get stale. Particularly in the blog commenting scenario where the user my acquire the positive assertion before writing his blog comment and thereby could wait 15 minutes or more before posting his comment.

So far, I'm mitigating this at the RP by choosing a "reasonable" maximum lifetime for the assertion and the javascript automatically renews the positive assertion after the assertion is assumed to have expired. But since this guess at the assertion's lifetime is not correct for an arbitrary OP, it would be great if with the positive assertion signed with a private association the OP could indicate with another parameter how long the assertion is valid for so the RP javascript code can renew at the optimal interval.

What do you think?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [OpenID] RP library authors

2009-09-11T16:31:31Z

I would like to say there is some hidden plan that explains it, but no
it is an error.

The tech writer will be reprimanded.

I will have that fixed.

Thanks
John B.

On 2009-09-11, at 7:15 PM, Tatsuki Sakushima wrote:

> Hi John,
>
> The document misses a reference to the PAPE spec in Appendix D.
> Is that done on purpose until some errors in the spec will be fixed?
>
> Tatsuki
>
> Tatsuki Sakushima
> NRI Pacific - Nomura Research Institute America, Inc.
>
> (9/11/09 8:49 AM), John Bradley wrote:
>> The GSA profile for openID is available at:
>> http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdf
>> Many things that are SHOULD in the openID 2.0 spec are now MUST in
>> the profile.
>> There are new PAPE URI and other modifications.
>> Most of the OP's supporting the profile will not be restricting it
>> to only Gov RP's.
>> Any RP may elect to use all or parts of this new profile for any
>> purpose they choose.
>> Also any OP is free to support it wether or not they are on the GSA
>> whitelist.
>> To get on the GSA white-list OP's must support the profile and be
>> audited against a Trust Framework. The OIDF has information
>> available an applying through it's program.
>> There are quite a number of requirements on the RP side, that need
>> to be met.
>> The sooner these features are in libraries the sooner government
>> agencies can move ahead with deployments.
>> If there is interest we can set up a google group where developers
>> can get there questions on implementing the profile answered.
>> If I can get to IIW in Nov, I would like to organize a session on
>> this for people.
>> There will be revisions to the profile in the future as we all gain
>> experience.
>> The people who worked on the profile tried to profile only the
>> existing specifications as written without inventing anything
>> incompatible with existing implementations.
>> The GSA's goal is to enable as many existing identities as possible
>> to have access to govenment resources without making people create
>> new username and password accounts at each of the thousands of
>> potential RP sites.
>> Extra attention was taken to allow openID to be used without
>> divulging ANY PII to the government.
>> This includes the use of a Pseudonymous openID identifier to allow
>> sites that can take no PII or do any correlation to still use openID.
>> The regulation on this is quite strict. We could not convert the
>> ID to a pseudonym on the RP side and adhere to the regulation.
>> We hope that the profile maximizes participation of OP's and RPs
>> alike, while not placing insurmountable burdens on developers.
>> RP's and OP's that don't intend to make use of the profile need to
>> make no changes at all.
>> I regret bot being able to share more of this with you sooner. The
>> OIDF and the other foundations were requested not to discuss this
>> publicly until after the government announcements.
>> Regards
>> John Bradley
>> _______________________________________________
>> specs mailing list
>> specs@...
>> http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

Re: [OpenID] RP library authors

2009-09-11T16:15:43Z

Hi John,

The document misses a reference to the PAPE spec in Appendix D.
Is that done on purpose until some errors in the spec will be fixed?

Tatsuki

Tatsuki Sakushima
NRI Pacific - Nomura Research Institute America, Inc.

(9/11/09 8:49 AM), John Bradley wrote:

> The GSA profile for openID is available at:
>
> http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdf
>
> Many things that are SHOULD in the openID 2.0 spec are now MUST in the
> profile.
>
> There are new PAPE URI and other modifications.
>
> Most of the OP's supporting the profile will not be restricting it to
> only Gov RP's.
>
> Any RP may elect to use all or parts of this new profile for any purpose
> they choose.
>
> Also any OP is free to support it wether or not they are on the GSA
> whitelist.
>
> To get on the GSA white-list OP's must support the profile and be
> audited against a Trust Framework. The OIDF has information available
> an applying through it's program.
>
> There are quite a number of requirements on the RP side, that need to be
> met.
>
> The sooner these features are in libraries the sooner government
> agencies can move ahead with deployments.
>
> If there is interest we can set up a google group where developers can
> get there questions on implementing the profile answered.
>
> If I can get to IIW in Nov, I would like to organize a session on this
> for people.
>
> There will be revisions to the profile in the future as we all gain
> experience.
>
> The people who worked on the profile tried to profile only the existing
> specifications as written without inventing anything incompatible with
> existing implementations.
>
> The GSA's goal is to enable as many existing identities as possible to
> have access to govenment resources without making people create new
> username and password accounts at each of the thousands of potential RP
> sites.
>
> Extra attention was taken to allow openID to be used without divulging
> ANY PII to the government.
> This includes the use of a Pseudonymous openID identifier to allow sites
> that can take no PII or do any correlation to still use openID.
>
> The regulation on this is quite strict. We could not convert the ID to
> a pseudonym on the RP side and adhere to the regulation.
>
> We hope that the profile maximizes participation of OP's and RPs alike,
> while not placing insurmountable burdens on developers.
>
> RP's and OP's that don't intend to make use of the profile need to make
> no changes at all.
>
> I regret bot being able to share more of this with you sooner. The OIDF
> and the other foundations were requested not to discuss this publicly
> until after the government announcements.
>
> Regards
> John Bradley
>
>
>
> _______________________________________________
> specs mailing list
> specs@...
> http://lists.openid.net/mailman/listinfo/openid-specs
>

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[OpenID] RP library authors

2009-09-11T08:49:18Z

The GSA profile for openID is available at:

http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdf

Many things that are SHOULD in the openID 2.0 spec are now MUST in the
profile.

There are new PAPE URI and other modifications.

Most of the OP's supporting the profile will not be restricting it to
only Gov RP's.

Any RP may elect to use all or parts of this new profile for any
purpose they choose.

Also any OP is free to support it wether or not they are on the GSA
whitelist.

To get on the GSA white-list OP's must support the profile and be
audited against a Trust Framework. The OIDF has information available
an applying through it's program.

There are quite a number of requirements on the RP side, that need to
be met.

The sooner these features are in libraries the sooner government
agencies can move ahead with deployments.

If there is interest we can set up a google group where developers can
get there questions on implementing the profile answered.

If I can get to IIW in Nov, I would like to organize a session on
this for people.

There will be revisions to the profile in the future as we all gain
experience.

The people who worked on the profile tried to profile only the
existing specifications as written without inventing anything
incompatible with existing implementations.

The GSA's goal is to enable as many existing identities as possible to
have access to govenment resources without making people create new
username and password accounts at each of the thousands of potential
RP sites.

Extra attention was taken to allow openID to be used without divulging
ANY PII to the government.
This includes the use of a Pseudonymous openID identifier to allow
sites that can take no PII or do any correlation to still use openID.

The regulation on this is quite strict. We could not convert the ID
to a pseudonym on the RP side and adhere to the regulation.

We hope that the profile maximizes participation of OP's and RPs
alike, while not placing insurmountable burdens on developers.

RP's and OP's that don't intend to make use of the profile need to
make no changes at all.

I regret bot being able to share more of this with you sooner. The
OIDF and the other foundations were requested not to discuss this
publicly until after the government announcements.

Regards
John Bradley

_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

Re: XRD and OpenID 2.1

2009-09-04T10:57:08Z

Typing in a directed identity URL is perfectly acceptable, and
required for some OP Google if there is no dedicated button.

Unless we change openID 2.0 (a possibility) we currently have two
existing services <Type>
One for normal logins and one for identifier select.

We need one rel each for that. They exiting <Type> URI may well work.

I don't know that delegating is the correct word for this.
It is not necessarily openID delegation.

It is an indirection to another XRD to get more information about the
desired relationship.

In XRI 2.0 this was called a redirect, but was not used by XRDS-Simple.

How openID uses LRDD and XRD to resolve endpoints is not something
that will be in the XRD spec itself.

It may be that we decide we don't need a special rel for the provider
relationship and that having the media type application/xrd+xml on the
two current rels is sufficient.

One other thing to think about is that we do have optional <Type>
elements for PAPE, AX, SREG and perhaps others.

Should those go in the users XRD as hints to RPs as additional rel
pointing to the providers XRD?

There are a bunch of things that we need to discuss about how XRD can
be used for openID discovery.

John B.
On 2009-09-04, at 1:27 PM, Santosh Rajan wrote:

>
> If I understood you correctly, you are suggesting 2 endpoints and 1
> delegate
> Rel for Openid. The 2nd endpoint for identifier select.
>
> Now this is what I am not clear about. Pls correct me If I am wrong.
>
> 1) Since the subject of this discussion is the users XRD, identifier
> select
> is not relevant here. The RP already has the users claimed_id. That
> is what
> he would have typed in (his OpenID) to get to his XRD. Unless of
> cource he
> typed his email like identifier, (which is webfinger).
> 2) If the user typed in his directed identity (a misnomer according to
> some), that would be handled by his host-meta which would delegate
> to his
> XRDS like this.
> <XRD>
> <Host>example.com</Host>
> <Link>
> <Rel>http://openid.net/rel/delegate</Rel>
> <URI>http://whatever.com/08/id</URI>
> <MediaType>application/xrds+xml<MediaType>
> </Link>
> </XRD>
>
> Please note above the mediatype is "xrds" not "xrd".
>
> Also I think Nat's suggestion that we need a separate thread to
> discuss
> OpenID discovery WRT LRDD is what is required. I would go one step
> more and
> suggest we need a wiki page under "emerging tech".
> If nobody wants to do that, I will do that if I find time this
> weekend. :-)
>
>
> John Bradley-7 wrote:
>>
>> We still need two endpoints as well as the delegate to support
>> identifier select with openID 2.0.
>>
>> John B.
>> On 2009-09-03, at 9:30 AM, Santosh Rajan wrote:
>>
>>> To make discovery easier for an RP, I suggest we limit the RP to
>>> look for one of two resources in a users XRD.
>>> 1) An OpenID Endpoint
>>> 2) An OpenID Delegate.
>>> If an OpenID endpoint is not available in a users XRD, the RP will
>>> next look for a delegated host. In both cases the RP is looking for
>>> a Rel value in a Link Element. So I suggest something like this for
>>> Rel values
>>> 1) http://openid.net/rel/endpoint
>>> 2) http://openid.net/rel/delegate
>>>
>>> On Thu, Sep 3, 2009 at 10:55 AM, Nat Sakimura <n-sakimura@...>
>>> wrote:
>>> The first XRD in my example is the "User Discovery" XRD in Dirk's
>>> post.
>>> I am talking about what to use for <rel> URI here.
>>> In XRI TC's discussion, we disccussed that it probably is not
>>> right to
>>> use the same URI for both "User Discovery" document (which defines
>>> relationship, "Relationship URI") and "Provider Discovery" (which
>>> defines the service).
>>> I suppose Dirk is using the same URI just for the lack of this
>>> "Relationship URI".
>>>
>>> Also, in Dirk's example, in User Discovery, he is siting
>>> <URI>http://openid.example.com/op</URI>
>>>
>>> I suppose this is somewhat misleading.
>>> I suppose it should be
>>>
>>> <URI>http://example.com/#<URI>
>>>
>>> (Note: I have added # to denote that it is pointing to a non
>>> information resource.
>>> As it is a non-information resource, the matching information
>>> resource has to be
>>> discovered by some other protocol, such as LRDD/site-meta.)
>>>
>>> As to the Provider Discovery is concerned, there is no <Host> in the
>>> latest XRD schema.
>>> It is unified with <Subject>. How to express the "Subject Set" or
>>> entire domain is
>>> still under discussion, I believe, in site-meta discussion. The last
>>> I have seen is
>>> something like: <Subject>site-meta://example.com</Subject>.
>>> Personally, I do not like it. (W3C people will not either, I think.)
>>> What some XRI TC people suggested was to use something like
>>> <Subject>http://example.com/#</Subject> as in AWWW, but this is
>>> something
>>> that should be discussed in another thread.
>>>
>>> What I was referring to as "not sure" was whether we need to support
>>> all types of LRDD
>>> or just one, for OpenID. I have got an opinion on that but I am
>>> intending to start
>>> yet another thread for that. (Or somebody else can do so. I am
>>> rather time constrained.)
>>>
>>> I think it is a good practice to separate those threads and
>>> concentrate on one issue
>>> per thread so that we can avoid drifting discussion.
>>>
>>> This thread is only about the Relationship URI.
>>>
>>> =nat
>>>
>>>
>>>
>>> Santosh Rajan wrote:
>>>>
>>>> There is an article posted here related to this.
>>>> http://www.hueniverse.com/hueniverse/2009/09/openid-and-lrdd.html
>>>>
>>>> So how does this work in the above framework?
>>>>
>>>>
>>>> On Thu, Sep 3, 2009 at 9:26 AM, Nat Sakimura <n-sakimura@...>
>>>> wrote:
>>>> So, User's XRD would have something like
>>>>
>>>> <xrd id="foo">
>>>> <Subject>http://sakimura.org/nat</Subject>
>>>> <ds:Signature> ... </ds:Signature>
>>>> <link>
>>>> <rel>http://openid.net/rels/myopenid_provider</rel>
>>>> <url>http://myopenid.net/</url>
>>>> </link>
>>>> </xrd>
>>>>
>>>> This is fetched during the discovery. (I am still not so sure about
>>>> the relationship between X-XRDS-Location: header and site_meta etc.
>>>> Are we abandoning the header model?)
>>>>
>>>> Then, the RP searches for my relationship with OP through <rel>.
>>>> Once it was found, the RP goes to the url specified in the <link>
>>>> to
>>>> get the Service's XRD like:
>>>>
>>>> <xrd id="baa">
>>>> <Subject>http://myopenid.net/</Subject>
>>>> <ds:Signature>...</ds:Signature>
>>>> <link>
>>>> <rel>http://openid.net/op/endpoint</rel>
>>>> <url>http://specs.openid.net/auth/2.0</url>
>>>> </link>
>>>> </xrd>
>>>>
>>>> to find out the concrete endpoint of this authentication service.
>>>>
>>>> =nat
>>>>
>>>>
>>>> John Bradley wrote:
>>>> Allen,
>>>>
>>>> In XRD 1.0 we are moving to a link based model.
>>>>
>>>> So a users XRD rather than having to specify the openID providers
>>>> service can point to an openID provider.
>>>>
>>>> The URIs that we currently use describe the service not the
>>>> provider.
>>>>
>>>> I think Nat is looking for a link relationship that describes a
>>>> user pointing to a service providers XRD rather than to the
>>>> service itself.
>>>>
>>>> There will be a bunch of new link types required for various
>>>> protocols.
>>>>
>>>> John B.
>>>>
>>>>
>>>> On 2009-09-02, at 5:27 PM, Allen Tom wrote:
>>>>
>>>> Hi Nat,
>>>>
>>>> Can you explain the problem in a bit more detail? Can you give an
>>>> example use case?
>>>>
>>>> Thanks
>>>> Allen
>>>>
>>>>
>>>> Nat Sakimura wrote:
>>>> The second topic for OpenID 2.1
>>>>
>>>> Maybe, it should be separated to the Discovery but...
>>>>
>>>> In XRD 1.0, we need to define <Rel> type url for the user=OP
>>>> relationship.
>>>> What shall we use?
>>>>
>>>> Something like:
>>>>
>>>> http://specs.openid.net/rel/openid_provider#
>>>>
>>>> =nat
>>>> _______________________________________________
>>>> specs mailing list
>>>> specs@...
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>> _______________________________________________
>>>> specs mailing list
>>>> specs@...
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>> _______________________________________________
>>>> specs mailing list
>>>> specs@...
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>>
>>>>
>>>> --
>>>> http://santrajan.blogspot.com
>>>> http://twitter.com/santoshrajan
>>>> http://www.facebook.com/santosh.rajan
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> http://santrajan.blogspot.com
>>> http://twitter.com/santoshrajan
>>> http://www.facebook.com/santosh.rajan
>>>
>>>
>>
>>
>> _______________________________________________
>> specs mailing list
>> specs@...
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>
>
> -----
>
> Santosh Rajan
> http://santrajan.blogspot.com http://santrajan.blogspot.com
> --
> View this message in context: http://www.nabble.com/XRD-and-OpenID-2.1-tp25252899p25298589.html
> Sent from the OpenID - Specs mailing list archive at Nabble.com.
>
> _______________________________________________
> specs mailing list
> specs@...
> http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: XRD and OpenID 2.1

2009-09-04T10:27:57Z

If I understood you correctly, you are suggesting 2 endpoints and 1 delegate Rel for Openid. The 2nd endpoint for identifier select.

Now this is what I am not clear about. Pls correct me If I am wrong.

1) Since the subject of this discussion is the users XRD, identifier select is not relevant here. The RP already has the users claimed_id. That is what he would have typed in (his OpenID) to get to his XRD. Unless of cource he typed his email like identifier, (which is webfinger).
2) If the user typed in his directed identity (a misnomer according to some), that would be handled by his host-meta which would delegate to his XRDS like this.
<XRD>
<Host>example.com</Host>
<Link>
<Rel>http://openid.net/rel/delegate</Rel>
<URI>http://whatever.com/08/id</URI>
<MediaType>application/xrds+xml<MediaType>
</Link>
</XRD>

Please note above the mediatype is "xrds" not "xrd".

Also I think Nat's suggestion that we need a separate thread to discuss OpenID discovery WRT LRDD is what is required. I would go one step more and suggest we need a wiki page under "emerging tech".
If nobody wants to do that, I will do that if I find time this weekend. :-)

John Bradley-7 wrote:

We still need two endpoints as well as the delegate to support
identifier select with openID 2.0.

John B.
On 2009-09-03, at 9:30 AM, Santosh Rajan wrote:

> To make discovery easier for an RP, I suggest we limit the RP to
> look for one of two resources in a users XRD.
> 1) An OpenID Endpoint
> 2) An OpenID Delegate.
> If an OpenID endpoint is not available in a users XRD, the RP will
> next look for a delegated host. In both cases the RP is looking for
> a Rel value in a Link Element. So I suggest something like this for
> Rel values
> 1) http://openid.net/rel/endpoint
> 2) http://openid.net/rel/delegate
>
> On Thu, Sep 3, 2009 at 10:55 AM, Nat Sakimura <n-sakimura@nri.co.jp>
> wrote:
> The first XRD in my example is the "User Discovery" XRD in Dirk's
> post.
> I am talking about what to use for <rel> URI here.
> In XRI TC's discussion, we disccussed that it probably is not right to
> use the same URI for both "User Discovery" document (which defines
> relationship, "Relationship URI") and "Provider Discovery" (which
> defines the service).
> I suppose Dirk is using the same URI just for the lack of this
> "Relationship URI".
>
> Also, in Dirk's example, in User Discovery, he is siting
> <URI>http://openid.example.com/op</URI>
>
> I suppose this is somewhat misleading.
> I suppose it should be
>
> <URI>http://example.com/#<URI>
>
> (Note: I have added # to denote that it is pointing to a non
> information resource.
> As it is a non-information resource, the matching information
> resource has to be
> discovered by some other protocol, such as LRDD/site-meta.)
>
> As to the Provider Discovery is concerned, there is no <Host> in the
> latest XRD schema.
> It is unified with <Subject>. How to express the "Subject Set" or
> entire domain is
> still under discussion, I believe, in site-meta discussion. The last
> I have seen is
> something like: <Subject>site-meta://example.com</Subject>.
> Personally, I do not like it. (W3C people will not either, I think.)
> What some XRI TC people suggested was to use something like
> <Subject>http://example.com/#</Subject> as in AWWW, but this is
> something
> that should be discussed in another thread.
>
> What I was referring to as "not sure" was whether we need to support
> all types of LRDD
> or just one, for OpenID. I have got an opinion on that but I am
> intending to start
> yet another thread for that. (Or somebody else can do so. I am
> rather time constrained.)
>
> I think it is a good practice to separate those threads and
> concentrate on one issue
> per thread so that we can avoid drifting discussion.
>
> This thread is only about the Relationship URI.
>
> =nat
>
>
>
> Santosh Rajan wrote:
>>
>> There is an article posted here related to this.
>> http://www.hueniverse.com/hueniverse/2009/09/openid-and-lrdd.html
>>
>> So how does this work in the above framework?
>>
>>
>> On Thu, Sep 3, 2009 at 9:26 AM, Nat Sakimura <n-sakimura@nri.co.jp>
>> wrote:
>> So, User's XRD would have something like
>>
>> <xrd id="foo">
>> <Subject>http://sakimura.org/nat</Subject>
>> <ds:Signature> ... </ds:Signature>
>> <link>
>> <rel>http://openid.net/rels/myopenid_provider</rel>
>> <url>http://myopenid.net/</url>
>> </link>
>> </xrd>
>>
>> This is fetched during the discovery. (I am still not so sure about
>> the relationship between X-XRDS-Location: header and site_meta etc.
>> Are we abandoning the header model?)
>>
>> Then, the RP searches for my relationship with OP through <rel>.
>> Once it was found, the RP goes to the url specified in the <link> to
>> get the Service's XRD like:
>>
>> <xrd id="baa">
>> <Subject>http://myopenid.net/</Subject>
>> <ds:Signature>...</ds:Signature>
>> <link>
>> <rel>http://openid.net/op/endpoint</rel>
>> <url>http://specs.openid.net/auth/2.0</url>
>> </link>
>> </xrd>
>>
>> to find out the concrete endpoint of this authentication service.
>>
>> =nat
>>
>>
>> John Bradley wrote:
>> Allen,
>>
>> In XRD 1.0 we are moving to a link based model.
>>
>> So a users XRD rather than having to specify the openID providers
>> service can point to an openID provider.
>>
>> The URIs that we currently use describe the service not the provider.
>>
>> I think Nat is looking for a link relationship that describes a
>> user pointing to a service providers XRD rather than to the
>> service itself.
>>
>> There will be a bunch of new link types required for various
>> protocols.
>>
>> John B.
>>
>>
>> On 2009-09-02, at 5:27 PM, Allen Tom wrote:
>>
>> Hi Nat,
>>
>> Can you explain the problem in a bit more detail? Can you give an
>> example use case?
>>
>> Thanks
>> Allen
>>
>>
>> Nat Sakimura wrote:
>> The second topic for OpenID 2.1
>>
>> Maybe, it should be separated to the Discovery but...
>>
>> In XRD 1.0, we need to define <Rel> type url for the user=OP
>> relationship.
>> What shall we use?
>>
>> Something like:
>>
>> http://specs.openid.net/rel/openid_provider#
>>
>> =nat
>> _______________________________________________
>> specs mailing list
>> specs@lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>> _______________________________________________
>> specs mailing list
>> specs@lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>> _______________________________________________
>> specs mailing list
>> specs@lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>>
>> --
>> http://santrajan.blogspot.com
>> http://twitter.com/santoshrajan
>> http://www.facebook.com/santosh.rajan
>>
>>
>
>
>
> --
> http://santrajan.blogspot.com
> http://twitter.com/santoshrajan
> http://www.facebook.com/santosh.rajan
>
>

_______________________________________________
specs mailing list
specs@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Santosh Rajan http://santrajan.blogspot.com

Re: XRD and OpenID 2.1

2009-09-04T09:57:53Z

Yes, http://openid.net/rel/my_op looks better.

Nat Sakimura-2 wrote:

You do not want to state the endpoint. You only want to sate the
provider, IMHO.
So, http://openid.net/rel/endpoint would not be a good naming.
I like something in the line of

http://openid.net/rel/op etc. or more verbose version of it like:
http://openid.net/rel/my_op etc.

=nat

Santosh Rajan wrote:
> To make discovery easier for an RP, I suggest we limit the RP to look
> for one of two resources in a users XRD.
> 1) An OpenID Endpoint
> 2) An OpenID Delegate.
> If an OpenID endpoint is not available in a users XRD, the RP will
> next look for a delegated host. In both cases the RP is looking for a
> Rel value in a Link Element. So I suggest something like this for Rel
> values
> 1) http://openid.net/rel/endpoint <http://openid.net/op/endpoint>
> 2) http://openid.net <http://openid.net/op/endpoint>/rel/delegate
>
> On Thu, Sep 3, 2009 at 10:55 AM, Nat Sakimura <n-sakimura@nri.co.jp
> <mailto:n-sakimura@nri.co.jp>> wrote:
>
> The first XRD in my example is the "User Discovery" XRD in Dirk's
> post.
> I am talking about what to use for <rel> URI here.
> In XRI TC's discussion, we disccussed that it probably is not
> right to
> use the same URI for both "User Discovery" document (which defines
> relationship, "Relationship URI") and "Provider Discovery" (which
> defines the service).
> I suppose Dirk is using the same URI just for the lack of this
> "Relationship URI".
>
> Also, in Dirk's example, in User Discovery, he is siting
> <URI>http://openid.example.com/op</URI>
>
> I suppose this is somewhat misleading.
> I suppose it should be
>
> <URI>http://example.com/#<URI>
>
> (Note: I have added # to denote that it is pointing to a non
> information resource.
> As it is a non-information resource, the matching information
> resource has to be
> discovered by some other protocol, such as LRDD/site-meta.)
>
> As to the Provider Discovery is concerned, there is no <Host> in
> the latest XRD schema.
> It is unified with <Subject>. How to express the "Subject Set" or
> entire domain is
> still under discussion, I believe, in site-meta discussion. The
> last I have seen is
> something like: <Subject>site-meta://example.com
> <http://example.com></Subject>.
> Personally, I do not like it. (W3C people will not either, I think.)
> What some XRI TC people suggested was to use something like
> <Subject>http://example.com/#</Subject> as in AWWW, but this is
> something
> that should be discussed in another thread.
>
> What I was referring to as "not sure" was whether we need to
> support all types of LRDD
> or just one, for OpenID. I have got an opinion on that but I am
> intending to start
> yet another thread for that. (Or somebody else can do so. I am
> rather time constrained.)
>
> I think it is a good practice to separate those threads and
> concentrate on one issue
> per thread so that we can avoid drifting discussion.
>
> This thread is only about the Relationship URI.
>
> =nat
>
>
>
> Santosh Rajan wrote:
>> There is an article posted here related to this.
>> http://www.hueniverse.com/hueniverse/2009/09/openid-and-lrdd.html
>>
>> So how does this work in the above framework?
>>
>>
>> On Thu, Sep 3, 2009 at 9:26 AM, Nat Sakimura
>> <n-sakimura@nri.co.jp <mailto:n-sakimura@nri.co.jp>> wrote:
>>
>> So, User's XRD would have something like
>>
>> <xrd id="foo">
>> <Subject>http://sakimura.org/nat</Subject>
>> <ds:Signature> ... </ds:Signature>
>> <link>
>> <rel>http://openid.net/rels/myopenid_provider</rel>
>> <url>http://myopenid.net/</url>
>> </link>
>> </xrd>
>>
>> This is fetched during the discovery. (I am still not so sure
>> about
>> the relationship between X-XRDS-Location: header and
>> site_meta etc.
>> Are we abandoning the header model?)
>>
>> Then, the RP searches for my relationship with OP through <rel>.
>> Once it was found, the RP goes to the url specified in the
>> <link> to
>> get the Service's XRD like:
>>
>> <xrd id="baa">
>> <Subject>http://myopenid.net/</Subject>
>> <ds:Signature>...</ds:Signature>
>> <link>
>> <rel>http://openid.net/op/endpoint</rel>
>> <url>http://specs.openid.net/auth/2.0</url>
>> </link>
>> </xrd>
>>
>> to find out the concrete endpoint of this authentication service.
>>
>> =nat
>>
>>
>> John Bradley wrote:
>>
>> Allen,
>>
>> In XRD 1.0 we are moving to a link based model.
>>
>> So a users XRD rather than having to specify the openID
>> providers service can point to an openID provider.
>>
>> The URIs that we currently use describe the service not
>> the provider.
>>
>> I think Nat is looking for a link relationship that
>> describes a user pointing to a service providers XRD
>> rather than to the service itself.
>>
>> There will be a bunch of new link types required for
>> various protocols.
>>
>> John B.
>>
>>
>> On 2009-09-02, at 5:27 PM, Allen Tom wrote:
>>
>> Hi Nat,
>>
>> Can you explain the problem in a bit more detail? Can
>> you give an example use case?
>>
>> Thanks
>> Allen
>>
>>
>> Nat Sakimura wrote:
>>
>> The second topic for OpenID 2.1
>>
>> Maybe, it should be separated to the Discovery but...
>>
>> In XRD 1.0, we need to define <Rel> type url for
>> the user=OP relationship.
>> What shall we use?
>>
>> Something like:
>>
>> http://specs.openid.net/rel/openid_provider#
>>
>> =nat
>> _______________________________________________
>> specs mailing list
>> specs@lists.openid.net
>> <mailto:specs@lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>> _______________________________________________
>> specs mailing list
>> specs@lists.openid.net <mailto:specs@lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>> _______________________________________________
>> specs mailing list
>> specs@lists.openid.net <mailto:specs@lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>>
>>
>> --
>> http://santrajan.blogspot.com
>> http://twitter.com/santoshrajan
>> http://www.facebook.com/santosh.rajan
>>
>>
>
>
>
> --
> http://santrajan.blogspot.com
> http://twitter.com/santoshrajan
> http://www.facebook.com/santosh.rajan
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> specs mailing list
> specs@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>

_______________________________________________
specs mailing list
specs@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Santosh Rajan http://santrajan.blogspot.com

Re: XRD and OpenID 2.1

2009-09-03T21:48:44Z

You do not want to state the endpoint. You only want to sate the provider, IMHO.
So, http://openid.net/rel/endpoint would not be a good naming.
I like something in the line of

http://openid.net/rel/op etc. or more verbose version of it like:
http://openid.net/rel/my_op etc.

=nat

Santosh Rajan wrote:

To make discovery easier for an RP, I suggest we limit the RP to look for one of two resources in a users XRD.
1) An OpenID Endpoint

2) An OpenID Delegate.

If an OpenID endpoint is not available in a users XRD, the RP will next look for a delegated host. In both cases the RP is looking for a Rel value in a Link Element. So I suggest something like this for Rel values

1) http://openid.net/rel/endpoint

2) http://openid.net/rel/delegate

On Thu, Sep 3, 2009 at 10:55 AM, Nat Sakimura <n-sakimura@...> wrote:

The first XRD in my example is the "User Discovery" XRD in Dirk's post.
I am talking about what to use for <rel> URI here.
In XRI TC's discussion, we disccussed that it probably is not right to
use the same URI for both "User Discovery" document (which defines
relationship, "Relationship URI") and "Provider Discovery" (which defines the service).
I suppose Dirk is using the same URI just for the lack of this "Relationship URI".

Also, in Dirk's example, in User Discovery, he is siting
<URI>http://openid.example.com/op</URI>

I suppose this is somewhat misleading.
I suppose it should be

<URI>http://example.com/#<URI>

(Note: I have added # to denote that it is pointing to a non information resource.
As it is a non-information resource, the matching information resource has to be
discovered by some other protocol, such as LRDD/site-meta.)

As to the Provider Discovery is concerned, there is no <Host> in the latest XRD schema.
It is unified with <Subject>. How to express the "Subject Set" or entire domain is
still under discussion, I believe, in site-meta discussion. The last I have seen is
something like: <Subject>site-meta://example.com</Subject>.
Personally, I do not like it. (W3C people will not either, I think.)
What some XRI TC people suggested was to use something like
<Subject>http://example.com/#</Subject> as in AWWW, but this is something
that should be discussed in another thread.

What I was referring to as "not sure" was whether we need to support all types of LRDD
or just one, for OpenID. I have got an opinion on that but I am intending to start
yet another thread for that. (Or somebody else can do so. I am rather time constrained.)

I think it is a good practice to separate those threads and concentrate on one issue
per thread so that we can avoid drifting discussion.

This thread is only about the Relationship URI.

=nat

Santosh Rajan wrote:
There is an article posted here related to this.
http://www.hueniverse.com/hueniverse/2009/09/openid-and-lrdd.html

So how does this work in the above framework?

On Thu, Sep 3, 2009 at 9:26 AM, Nat Sakimura <n-sakimura@...> wrote:

So, User's XRD would have something like

<xrd id="foo">
<Subject>http://sakimura.org/nat</Subject>
<ds:Signature> ... </ds:Signature>
<link>
<rel>http://openid.net/rels/myopenid_provider</rel>
<url>http://myopenid.net/</url>
</link>
</xrd>

This is fetched during the discovery. (I am still not so sure about
the relationship between X-XRDS-Location: header and site_meta etc.
Are we abandoning the header model?)

Then, the RP searches for my relationship with OP through <rel>.
Once it was found, the RP goes to the url specified in the <link> to
get the Service's XRD like:

<xrd id="baa">
<Subject>http://myopenid.net/</Subject>
<ds:Signature>...</ds:Signature>
<link>
<rel>http://openid.net/op/endpoint</rel>
<url>http://specs.openid.net/auth/2.0</url>
</link>
</xrd>

to find out the concrete endpoint of this authentication service.

=nat

John Bradley wrote:

Allen,

In XRD 1.0 we are moving to a link based model.

So a users XRD rather than having to specify the openID providers service can point to an openID provider.

The URIs that we currently use describe the service not the provider.

I think Nat is looking for a link relationship that describes a user pointing to a service providers XRD rather than to the service itself.

There will be a bunch of new link types required for various protocols.

John B.

On 2009-09-02, at 5:27 PM, Allen Tom wrote:

Hi Nat,

Can you explain the problem in a bit more detail? Can you give an example use case?

Thanks
Allen

Nat Sakimura wrote:

The second topic for OpenID 2.1

Maybe, it should be separated to the Discovery but...

In XRD 1.0, we need to define <Rel> type url for the user=OP relationship.
What shall we use?

Something like:

http://specs.openid.net/rel/openid_provider#

=nat
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

--
http://santrajan.blogspot.com
http://twitter.com/santoshrajan
http://www.facebook.com/santosh.rajan

--
http://santrajan.blogspot.com
http://twitter.com/santoshrajan
http://www.facebook.com/santosh.rajan
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
  

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: XRD and OpenID 2.1

2009-09-03T13:35:59Z

We still need two endpoints as well as the delegate to support identifier select with openID 2.0.

John B.

On 2009-09-03, at 9:30 AM, Santosh Rajan wrote:

To make discovery easier for an RP, I suggest we limit the RP to look for one of two resources in a users XRD.
1) An OpenID Endpoint
2) An OpenID Delegate.
If an OpenID endpoint is not available in a users XRD, the RP will next look for a delegated host. In both cases the RP is looking for a Rel value in a Link Element. So I suggest something like this for Rel values

1) http://openid.net/rel/endpoint

2) http://openid.net/rel/delegate

On Thu, Sep 3, 2009 at 10:55 AM, Nat Sakimura <n-sakimura@...> wrote:

The first XRD in my example is the "User Discovery" XRD in Dirk's post.
I am talking about what to use for <rel> URI here.
In XRI TC's discussion, we disccussed that it probably is not right to
use the same URI for both "User Discovery" document (which defines
relationship, "Relationship URI") and "Provider Discovery" (which defines the service).
I suppose Dirk is using the same URI just for the lack of this "Relationship URI".

Also, in Dirk's example, in User Discovery, he is siting
<URI>http://openid.example.com/op</URI>

I suppose this is somewhat misleading.
I suppose it should be

<URI>http://example.com/#<URI>

(Note: I have added # to denote that it is pointing to a non information resource.
As it is a non-information resource, the matching information resource has to be
discovered by some other protocol, such as LRDD/site-meta.)

As to the Provider Discovery is concerned, there is no <Host> in the latest XRD schema.
It is unified with <Subject>. How to express the "Subject Set" or entire domain is
still under discussion, I believe, in site-meta discussion. The last I have seen is
something like: <Subject>site-meta://example.com</Subject>.
Personally, I do not like it. (W3C people will not either, I think.)
What some XRI TC people suggested was to use something like
<Subject>http://example.com/#</Subject> as in AWWW, but this is something
that should be discussed in another thread.

What I was referring to as "not sure" was whether we need to support all types of LRDD
or just one, for OpenID. I have got an opinion on that but I am intending to start
yet another thread for that. (Or somebody else can do so. I am rather time constrained.)

I think it is a good practice to separate those threads and concentrate on one issue
per thread so that we can avoid drifting discussion.

This thread is only about the Relationship URI.

=nat

Santosh Rajan wrote:
There is an article posted here related to this.
http://www.hueniverse.com/hueniverse/2009/09/openid-and-lrdd.html

So how does this work in the above framework?

On Thu, Sep 3, 2009 at 9:26 AM, Nat Sakimura <n-sakimura@...> wrote:

So, User's XRD would have something like

<xrd id="foo">
<Subject>http://sakimura.org/nat</Subject>
<ds:Signature> ... </ds:Signature>
<link>
<rel>http://openid.net/rels/myopenid_provider</rel>
<url>http://myopenid.net/</url>
</link>
</xrd>

This is fetched during the discovery. (I am still not so sure about
the relationship between X-XRDS-Location: header and site_meta etc.
Are we abandoning the header model?)

Then, the RP searches for my relationship with OP through <rel>.
Once it was found, the RP goes to the url specified in the <link> to
get the Service's XRD like:

<xrd id="baa">
<Subject>http://myopenid.net/</Subject>
<ds:Signature>...</ds:Signature>
<link>
<rel>http://openid.net/op/endpoint</rel>
<url>http://specs.openid.net/auth/2.0</url>
</link>
</xrd>

to find out the concrete endpoint of this authentication service.

=nat

John Bradley wrote:

Allen,

In XRD 1.0 we are moving to a link based model.

So a users XRD rather than having to specify the openID providers service can point to an openID provider.

The URIs that we currently use describe the service not the provider.

I think Nat is looking for a link relationship that describes a user pointing to a service providers XRD rather than to the service itself.

There will be a bunch of new link types required for various protocols.

John B.

On 2009-09-02, at 5:27 PM, Allen Tom wrote:

Hi Nat,

Can you explain the problem in a bit more detail? Can you give an example use case?

Thanks
Allen

Nat Sakimura wrote:

The second topic for OpenID 2.1

Maybe, it should be separated to the Discovery but...

In XRD 1.0, we need to define <Rel> type url for the user=OP relationship.
What shall we use?

Something like:

http://specs.openid.net/rel/openid_provider#

=nat
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

--
http://santrajan.blogspot.com
http://twitter.com/santoshrajan
http://www.facebook.com/santosh.rajan

--
http://santrajan.blogspot.com
http://twitter.com/santoshrajan
http://www.facebook.com/santosh.rajan

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: XRD and OpenID 2.1

2009-09-03T06:30:10Z

To make discovery easier for an RP, I suggest we limit the RP to look for one of two resources in a users XRD.

1) An OpenID Endpoint

2) An OpenID Delegate.

If an OpenID endpoint is not available in a users XRD, the RP will next look for a delegated host. In both cases the RP is looking for a Rel value in a Link Element. So I suggest something like this for Rel values

1) http://openid.net/rel/endpoint

2) http://openid.net/rel/delegate

On Thu, Sep 3, 2009 at 10:55 AM, Nat Sakimura <n-sakimura@...> wrote:

The first XRD in my example is the "User Discovery" XRD in Dirk's post.
I am talking about what to use for <rel> URI here.
In XRI TC's discussion, we disccussed that it probably is not right to
use the same URI for both "User Discovery" document (which defines
relationship, "Relationship URI") and "Provider Discovery" (which defines the service).
I suppose Dirk is using the same URI just for the lack of this "Relationship URI".

Also, in Dirk's example, in User Discovery, he is siting
<URI>http://openid.example.com/op</URI>

I suppose this is somewhat misleading.
I suppose it should be

<URI>http://example.com/#<URI>

(Note: I have added # to denote that it is pointing to a non information resource.
As it is a non-information resource, the matching information resource has to be
discovered by some other protocol, such as LRDD/site-meta.)

As to the Provider Discovery is concerned, there is no <Host> in the latest XRD schema.
It is unified with <Subject>. How to express the "Subject Set" or entire domain is
still under discussion, I believe, in site-meta discussion. The last I have seen is
something like: <Subject>site-meta://example.com</Subject>.
Personally, I do not like it. (W3C people will not either, I think.)
What some XRI TC people suggested was to use something like
<Subject>http://example.com/#</Subject> as in AWWW, but this is something
that should be discussed in another thread.

What I was referring to as "not sure" was whether we need to support all types of LRDD
or just one, for OpenID. I have got an opinion on that but I am intending to start
yet another thread for that. (Or somebody else can do so. I am rather time constrained.)

I think it is a good practice to separate those threads and concentrate on one issue
per thread so that we can avoid drifting discussion.

This thread is only about the Relationship URI.

=nat

Santosh Rajan wrote:
There is an article posted here related to this.
http://www.hueniverse.com/hueniverse/2009/09/openid-and-lrdd.html

So how does this work in the above framework?

On Thu, Sep 3, 2009 at 9:26 AM, Nat Sakimura <n-sakimura@...> wrote:

So, User's XRD would have something like

<xrd id="foo">
<Subject>http://sakimura.org/nat</Subject>
<ds:Signature> ... </ds:Signature>
<link>
<rel>http://openid.net/rels/myopenid_provider</rel>
<url>http://myopenid.net/</url>
</link>
</xrd>

This is fetched during the discovery. (I am still not so sure about
the relationship between X-XRDS-Location: header and site_meta etc.
Are we abandoning the header model?)

Then, the RP searches for my relationship with OP through <rel>.
Once it was found, the RP goes to the url specified in the <link> to
get the Service's XRD like:

<xrd id="baa">
<Subject>http://myopenid.net/</Subject>
<ds:Signature>...</ds:Signature>
<link>
<rel>http://openid.net/op/endpoint</rel>
<url>http://specs.openid.net/auth/2.0</url>
</link>
</xrd>

to find out the concrete endpoint of this authentication service.

=nat

John Bradley wrote:

Allen,

In XRD 1.0 we are moving to a link based model.

So a users XRD rather than having to specify the openID providers service can point to an openID provider.

The URIs that we currently use describe the service not the provider.

I think Nat is looking for a link relationship that describes a user pointing to a service providers XRD rather than to the service itself.

There will be a bunch of new link types required for various protocols.

John B.

On 2009-09-02, at 5:27 PM, Allen Tom wrote:

Hi Nat,

Can you explain the problem in a bit more detail? Can you give an example use case?

Thanks
Allen

Nat Sakimura wrote:

The second topic for OpenID 2.1

Maybe, it should be separated to the Discovery but...

In XRD 1.0, we need to define <Rel> type url for the user=OP relationship.
What shall we use?

Something like:

http://specs.openid.net/rel/openid_provider#

=nat
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

--
http://santrajan.blogspot.com
http://twitter.com/santoshrajan
http://www.facebook.com/santosh.rajan

--
http://santrajan.blogspot.com
http://twitter.com/santoshrajan
http://www.facebook.com/santosh.rajan

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Santosh Rajan http://santrajan.blogspot.com

Re: XRD and OpenID 2.1

2009-09-02T22:25:50Z

The first XRD in my example is the "User Discovery" XRD in Dirk's post.
I am talking about what to use for <rel> URI here.
In XRI TC's discussion, we disccussed that it probably is not right to
use the same URI for both "User Discovery" document (which defines
relationship, "Relationship URI") and "Provider Discovery" (which defines the service).
I suppose Dirk is using the same URI just for the lack of this "Relationship URI".

Also, in Dirk's example, in User Discovery, he is siting
<URI>http://openid.example.com/op</URI>

I suppose this is somewhat misleading.
I suppose it should be

<URI>http://example.com/#<URI>

(Note: I have added # to denote that it is pointing to a non information resource.
As it is a non-information resource, the matching information resource has to be
discovered by some other protocol, such as LRDD/site-meta.)

As to the Provider Discovery is concerned, there is no <Host> in the latest XRD schema.
It is unified with <Subject>. How to express the "Subject Set" or entire domain is
still under discussion, I believe, in site-meta discussion. The last I have seen is
something like: <Subject>site-meta://example.com</Subject>.
Personally, I do not like it. (W3C people will not either, I think.)
What some XRI TC people suggested was to use something like
<Subject>http://example.com/#</Subject> as in AWWW, but this is something
that should be discussed in another thread.

What I was referring to as "not sure" was whether we need to support all types of LRDD
or just one, for OpenID. I have got an opinion on that but I am intending to start
yet another thread for that. (Or somebody else can do so. I am rather time constrained.)

I think it is a good practice to separate those threads and concentrate on one issue
per thread so that we can avoid drifting discussion.

This thread is only about the Relationship URI.

=nat

Santosh Rajan wrote:

There is an article posted here related to this.
http://www.hueniverse.com/hueniverse/2009/09/openid-and-lrdd.html

So how does this work in the above framework?

On Thu, Sep 3, 2009 at 9:26 AM, Nat Sakimura <n-sakimura@...> wrote:

So, User's XRD would have something like

<xrd id="foo">
<Subject>http://sakimura.org/nat</Subject>
<ds:Signature> ... </ds:Signature>
<link>
<rel>http://openid.net/rels/myopenid_provider</rel>
<url>http://myopenid.net/</url>
</link>
</xrd>

This is fetched during the discovery. (I am still not so sure about
the relationship between X-XRDS-Location: header and site_meta etc.
Are we abandoning the header model?)

Then, the RP searches for my relationship with OP through <rel>.
Once it was found, the RP goes to the url specified in the <link> to
get the Service's XRD like:

<xrd id="baa">
<Subject>http://myopenid.net/</Subject>
<ds:Signature>...</ds:Signature>
<link>
<rel>http://openid.net/op/endpoint</rel>
<url>http://specs.openid.net/auth/2.0</url>
</link>
</xrd>

to find out the concrete endpoint of this authentication service.

=nat

John Bradley wrote:

Allen,

In XRD 1.0 we are moving to a link based model.

So a users XRD rather than having to specify the openID providers service can point to an openID provider.

The URIs that we currently use describe the service not the provider.

I think Nat is looking for a link relationship that describes a user pointing to a service providers XRD rather than to the service itself.

There will be a bunch of new link types required for various protocols.

John B.

On 2009-09-02, at 5:27 PM, Allen Tom wrote:

Hi Nat,

Can you explain the problem in a bit more detail? Can you give an example use case?

Thanks
Allen

Nat Sakimura wrote:

The second topic for OpenID 2.1

Maybe, it should be separated to the Discovery but...

In XRD 1.0, we need to define <Rel> type url for the user=OP relationship.
What shall we use?

Something like:

http://specs.openid.net/rel/openid_provider#

=nat
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

--
http://santrajan.blogspot.com
http://twitter.com/santoshrajan
http://www.facebook.com/santosh.rajan

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: XRD and OpenID 2.1

2009-09-02T21:27:43Z

There is an article posted here related to this.

http://www.hueniverse.com/hueniverse/2009/09/openid-and-lrdd.html

So how does this work in the above framework?

On Thu, Sep 3, 2009 at 9:26 AM, Nat Sakimura <n-sakimura@...> wrote:

So, User's XRD would have something like

<xrd id="foo">
<Subject>http://sakimura.org/nat</Subject>
<ds:Signature> ... </ds:Signature>
<link>
<rel>http://openid.net/rels/myopenid_provider</rel>
<url>http://myopenid.net/</url>
</link>
</xrd>

This is fetched during the discovery. (I am still not so sure about
the relationship between X-XRDS-Location: header and site_meta etc.
Are we abandoning the header model?)

Then, the RP searches for my relationship with OP through <rel>.
Once it was found, the RP goes to the url specified in the <link> to
get the Service's XRD like:

<xrd id="baa">
<Subject>http://myopenid.net/</Subject>
<ds:Signature>...</ds:Signature>
<link>
<rel>http://openid.net/op/endpoint</rel>
<url>http://specs.openid.net/auth/2.0</url>
</link>
</xrd>

to find out the concrete endpoint of this authentication service.

=nat

John Bradley wrote:

Allen,

In XRD 1.0 we are moving to a link based model.

So a users XRD rather than having to specify the openID providers service can point to an openID provider.

The URIs that we currently use describe the service not the provider.

I think Nat is looking for a link relationship that describes a user pointing to a service providers XRD rather than to the service itself.

There will be a bunch of new link types required for various protocols.

John B.

On 2009-09-02, at 5:27 PM, Allen Tom wrote:

Hi Nat,

Can you explain the problem in a bit more detail? Can you give an example use case?

Thanks
Allen

Nat Sakimura wrote:

The second topic for OpenID 2.1

Maybe, it should be separated to the Discovery but...

In XRD 1.0, we need to define <Rel> type url for the user=OP relationship.
What shall we use?

Something like:

http://specs.openid.net/rel/openid_provider#

=nat
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

--
http://santrajan.blogspot.com
http://twitter.com/santoshrajan
http://www.facebook.com/santosh.rajan

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Santosh Rajan http://santrajan.blogspot.com

Re: XRD and OpenID 2.1

2009-09-02T20:56:18Z

So, User's XRD would have something like

<xrd id="foo">
<Subject>http://sakimura.org/nat</Subject>
<ds:Signature> ... </ds:Signature>
<link>
<rel>http://openid.net/rels/myopenid_provider</rel>
<url>http://myopenid.net/</url>
</link>
</xrd>

This is fetched during the discovery. (I am still not so sure about
the relationship between X-XRDS-Location: header and site_meta etc.
Are we abandoning the header model?)

Then, the RP searches for my relationship with OP through <rel>.
Once it was found, the RP goes to the url specified in the <link> to
get the Service's XRD like:

<xrd id="baa">
<Subject>http://myopenid.net/</Subject>
<ds:Signature>...</ds:Signature>
<link>
<rel>http://openid.net/op/endpoint</rel>
<url>http://specs.openid.net/auth/2.0</url>
</link>
</xrd>

to find out the concrete endpoint of this authentication service.

=nat

John Bradley wrote:

> Allen,
>
> In XRD 1.0 we are moving to a link based model.
>
> So a users XRD rather than having to specify the openID providers
> service can point to an openID provider.
>
> The URIs that we currently use describe the service not the provider.
>
> I think Nat is looking for a link relationship that describes a user
> pointing to a service providers XRD rather than to the service itself.
>
> There will be a bunch of new link types required for various protocols.
>
> John B.
>
>
> On 2009-09-02, at 5:27 PM, Allen Tom wrote:
>
>> Hi Nat,
>>
>> Can you explain the problem in a bit more detail? Can you give an
>> example use case?
>>
>> Thanks
>> Allen
>>
>>
>> Nat Sakimura wrote:
>>> The second topic for OpenID 2.1
>>>
>>> Maybe, it should be separated to the Discovery but...
>>>
>>> In XRD 1.0, we need to define <Rel> type url for the user=OP
>>> relationship.
>>> What shall we use?
>>>
>>> Something like:
>>>
>>> http://specs.openid.net/rel/openid_provider#
>>>
>>> =nat
>>> _______________________________________________
>>> specs mailing list
>>> specs@...
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>> _______________________________________________
>> specs mailing list
>> specs@...
>> http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: return_to url in the OpenID responses

2009-09-02T16:35:35Z

+1 for a relay state, but not for the size thing. This is a completely
separate issue than the Artifact binding.

Artifact binding is needed anyways for several reasons.

For example, mobile browsers etc., an Artifact binding is essential.
You must not think that that the transmission only happens over a fast
connection. In mobile scenarios, typically, the browser session is
over the slow connection while the server to server connection is over
a fast connection. So, latency-wise, the Artifact binding is going to
be much better, in fact, orders better, and kinder to an OP from the
point of view of number of simultaneous port that they have to keep
open. Also, you are talking about IE limit, but mobile browser limit
is much more severe, like 256 bytes per a GET query.

In addition, I would like to point out that over 70% of the traffic is
now generated from the mobile browsers. In the U.S., it might not have
happened yet, but you may be heading towards the direction as well.
People do not use a PC when it suffice with a Phone. User experience
is much better that way.

I would further say this: A protocol or service that can only be
provided over a single channel like PC is DEAD. It has to be provided
over mobile, PC internet, TV internet, etc. simultaneously. This is
not my word. This is the testimony from the EC (Electric Commerce)
consortium (I need to check their English name though...) at the
Japanese government meeting that discusses the authentication
guideline. IMHO, EU and US will come to the same state in a few years.

Also, the Artifact is needed for security reasons as well. You need it
for LoA2+. With the advent of Government 2.0, we need it NOW. We
should have done that long before.

=nat

On Thu, Sep 3, 2009 at 3:58 AM, Praveen
Alavilli<praveen.alavilli@...> wrote:

> Hi,
> I wasn't sure if this was ever discussed so sending it to the specs list.
> Currently the "openid.return_to" url param is a required parameter in all
> OpenID positive assertions. I understand the reasons behind it, but I wonder
> if passing back the whole return_to url (along with it's query params) as
> response param is really required. Returning the return_to url in the
> response just duplicates the same data that's already included in the
> response url contributing to the problem of the response url length close to
> or in some cases exceeding the max length allowed by certain browsers
> (IE!).
> Given that all the query parameters attached to the return_to param are
> anyway included in the redirect url, and the spec explicitly says that it's
> up to the RP to ensure those params are not modified by outside parties, can
> we:
>
> modify the signing method to include all query parameters (not just openid
> params) in the signature base string (follow something like the OAuth
> signing mechanism) and modify the openid.return_to param in the response to
> be just the request uri part (not including the rest of the non-OpenID RP
> specific parameters), OR
> add a new request parameter (say openid.rpState) that RPs can use to store
> their state/context info so they don't need to include them in the return_to
> url and so the OPs sign it along with the rest of the openid parameters in
> the response ?
>
> I know that there have been discussions going on about adding support for
> artifact binding to OpenID in 2.1 but that just unnecessarily adds
> additional requests for every OpenID login request. Not sure if the
> latencies incurred due to those are worth the effort. The other option to
> use a POST instead of a GET to avoid the url length issues causes bad back
> button user experience.
> Any other thoughts ?
> thanks
> Praveen
>
>
>
> _______________________________________________
> specs mailing list
> specs@...
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: XRD and OpenID 2.1

2009-09-02T16:01:28Z

Allen,

In XRD 1.0 we are moving to a link based model.

So a users XRD rather than having to specify the openID providers
service can point to an openID provider.

The URIs that we currently use describe the service not the provider.

I think Nat is looking for a link relationship that describes a user
pointing to a service providers XRD rather than to the service itself.

There will be a bunch of new link types required for various protocols.

John B.

On 2009-09-02, at 5:27 PM, Allen Tom wrote:

> Hi Nat,
>
> Can you explain the problem in a bit more detail? Can you give an
> example use case?
>
> Thanks
> Allen
>
>
> Nat Sakimura wrote:
>> The second topic for OpenID 2.1
>>
>> Maybe, it should be separated to the Discovery but...
>>
>> In XRD 1.0, we need to define <Rel> type url for the user=OP
>> relationship.
>> What shall we use?
>>
>> Something like:
>>
>> http://specs.openid.net/rel/openid_provider#
>>
>> =nat
>> _______________________________________________
>> specs mailing list
>> specs@...
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>
> _______________________________________________
> specs mailing list
> specs@...
> http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: XRD and OpenID 2.1

2009-09-02T14:27:45Z

Hi Nat,

Can you explain the problem in a bit more detail? Can you give an
example use case?

Thanks
Allen

Nat Sakimura wrote:

> The second topic for OpenID 2.1
>
> Maybe, it should be separated to the Discovery but...
>
> In XRD 1.0, we need to define <Rel> type url for the user=OP relationship.
> What shall we use?
>
> Something like:
>
> http://specs.openid.net/rel/openid_provider#
>
> =nat
> _______________________________________________
> specs mailing list
> specs@...
> http://lists.openid.net/mailman/listinfo/openid-specs
>

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: return_to url in the OpenID responses

2009-09-02T12:55:00Z

+1 for relay state and signing all parameters

Great point about discovery and dynamic parameters!

Thanks,
George

Breno de Medeiros wrote:

> +1 for a relay state
>
> In my view the OpenID spec is broken with regards to the return_to
> URL. For instance, how do you reconcile the need for dynamic elements
> in the return_to URL with the recommended behavior of putting the
> return_to URL in the discovery document?
>
>
> On Wed, Sep 2, 2009 at 11:58 AM, Praveen
> Alavilli<praveen.alavilli@...> wrote:
>
>> Hi,
>> I wasn't sure if this was ever discussed so sending it to the specs list.
>> Currently the "openid.return_to" url param is a required parameter in all
>> OpenID positive assertions. I understand the reasons behind it, but I wonder
>> if passing back the whole return_to url (along with it's query params) as
>> response param is really required. Returning the return_to url in the
>> response just duplicates the same data that's already included in the
>> response url contributing to the problem of the response url length close to
>> or in some cases exceeding the max length allowed by certain browsers
>> (IE!).
>> Given that all the query parameters attached to the return_to param are
>> anyway included in the redirect url, and the spec explicitly says that it's
>> up to the RP to ensure those params are not modified by outside parties, can
>> we:
>>
>> modify the signing method to include all query parameters (not just openid
>> params) in the signature base string (follow something like the OAuth
>> signing mechanism) and modify the openid.return_to param in the response to
>> be just the request uri part (not including the rest of the non-OpenID RP
>> specific parameters), OR
>> add a new request parameter (say openid.rpState) that RPs can use to store
>> their state/context info so they don't need to include them in the return_to
>> url and so the OPs sign it along with the rest of the openid parameters in
>> the response ?
>>
>> I know that there have been discussions going on about adding support for
>> artifact binding to OpenID in 2.1 but that just unnecessarily adds
>> additional requests for every OpenID login request. Not sure if the
>> latencies incurred due to those are worth the effort. The other option to
>> use a POST instead of a GET to avoid the url length issues causes bad back
>> button user experience.
>> Any other thoughts ?
>> thanks
>> Praveen
>>
>>
>>
>> _______________________________________________
>> specs mailing list
>> specs@...
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>>
>
>
>
>

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: return_to url in the OpenID responses

2009-09-02T12:02:35Z

+1 for a relay state

In my view the OpenID spec is broken with regards to the return_to
URL. For instance, how do you reconcile the need for dynamic elements
in the return_to URL with the recommended behavior of putting the
return_to URL in the discovery document?

On Wed, Sep 2, 2009 at 11:58 AM, Praveen
Alavilli<praveen.alavilli@...> wrote:

--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

return_to url in the OpenID responses

2009-09-02T11:58:49Z

Hi,

I wasn't sure if this was ever discussed so sending it to the specs list.

Currently the "openid.return_to" url param is a required parameter in all OpenID positive assertions. I understand the reasons behind it, but I wonder if passing back the whole return_to url (along with it's query params) as response param is really required. Returning the return_to url in the response just duplicates the same data that's already included in the response url contributing to the problem of the response url length close to or in some cases exceeding the max length allowed by certain browsers (IE!).

Given that all the query parameters attached to the return_to param are anyway included in the redirect url, and the spec explicitly says that it's up to the RP to ensure those params are not modified by outside parties, can we:

modify the signing method to include all query parameters (not just openid params) in the signature base string (follow something like the OAuth signing mechanism) and modify the openid.return_to param in the response to be just the request uri part (not including the rest of the non-OpenID RP specific parameters), OR
add a new request parameter (say openid.rpState) that RPs can use to store their state/context info so they don't need to include them in the return_to url and so the OPs sign it along with the rest of the openid parameters in the response ?

I know that there have been discussions going on about adding support for artifact binding to OpenID in 2.1 but that just unnecessarily adds additional requests for every OpenID login request. Not sure if the latencies incurred due to those are worth the effort. The other option to use a POST instead of a GET to avoid the url length issues causes bad back button user experience.

Any other thoughts ?

thanks

Praveen

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

XRD and OpenID 2.1

2009-09-02T00:28:53Z

The second topic for OpenID 2.1

Maybe, it should be separated to the Discovery but...

In XRD 1.0, we need to define <Rel> type url for the user=OP relationship.
What shall we use?

Something like:

http://specs.openid.net/rel/openid_provider#

=nat
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Some implementations don't process the HEAD element correctly

2009-08-26T18:23:08Z

Sorry I was unclear.

I wasn't criticizing openID 2.0 for being silent on where the meta tag
for X-XRDS.

Only that there is no requirement in the spec to place the other tags
in the HEAD.

That is the only unfortunate part.

John B.
On 26-Aug-09, at 4:48 PM, Josh Hoyt wrote:

> On Wed, Aug 26, 2009 at 8:24 AM, John
> Bradley<john.bradley@...> wrote:
>> Yadis requires the X-XRDS meta tag to be inside the <head> element.
>> OpenID 2.0 is silent on it.
>
> This is a little unfair to the OpenID 2.0 specification, since in
> order for a document to BE valid HTML[1] or XHTML[2], META tags are
> only allowed to be in the HEAD.
>
> It might have been nice for implementers if that relevant bit of
> information were duplicated in the OpenID 2.0 specification, but even
> without it, the requirement is well-specified.
>
> Josh
>
> 1. http://www.w3.org/TR/html401/sgml/dtd.html
> 2. http://www.w3.org/TR/xhtml1/dtds.html

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Some implementations don't process the HEAD element correctly

2009-08-26T13:48:48Z

On Wed, Aug 26, 2009 at 8:24 AM, John Bradley<john.bradley@...> wrote:
> Yadis requires the X-XRDS meta tag to be inside the <head> element.
> OpenID 2.0 is silent on it.

This is a little unfair to the OpenID 2.0 specification, since in
order for a document to BE valid HTML[1] or XHTML[2], META tags are
only allowed to be in the HEAD.

It might have been nice for implementers if that relevant bit of
information were duplicated in the OpenID 2.0 specification, but even
without it, the requirement is well-specified.

Josh

1. http://www.w3.org/TR/html401/sgml/dtd.html
2. http://www.w3.org/TR/xhtml1/dtds.html
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Some implementations don't process the HEAD element correctly

2009-08-26T08:24:24Z

There is talk of removing HTML discovery in future.

It is a known security problem.

Yadis requires the X-XRDS meta tag to be inside the <head> element.

OpenID 2.0 is silent on it.

Getting rid of the meta http-eqiv tag from the HTML will be a challenge, and a point for debate.

I think the other elements will go except for backwards compatibility with older RPs.

John B.

On 26-Aug-09, at 10:51 AM, Andrew Arnott wrote:

Thanks, Thomas. I hadn't meant to drop the list with my reply.

You're points are all correct too. I guess my only argument is: a fully compliant HTML parser in an OpenID RP library would be very heavyweight, and anything less would mean it's buggy. So far, the community seems satisfied with "mostly there" implementations. I agree it's not perfect, but in the next major OpenID spec, HTML discovery is likely to be removed anyway, so I don't think any implementers have motivation to fix these bugs that can easily be worked around.

BTW, missing HEAD tags is just one bug, and it seems disproportionate to stress this one over all the others. Some of which are perhaps more serious. I imagine many RPs don't ignore LINK tags that appear within HTML . And to properly respect comments requires Javascript parsing (I think!) in order to avoid ending the comment when a javascript function contains a string with "-->" in it.

Just some more thoughts. As an RP implementer myself, I do fix some HTML discovery bugs that come in, but not all of them for the reasons given above.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

On Wed, Aug 26, 2009 at 7:39 AM, Thomas Hühn <huehn@...> wrote:
[you mailed off-list, was that intentional?]

Andrew Arnott schrieb:

> The difference is "<LINK>" might appear somewhere in the <BODY> of the > page

Not in a valid HTML document. :-)

Of course you have to think about invalid ones as well, because browsers accept them.

But that doesn't have anything to do with whether there is a <HEAD> tag.

The security implications are totally independent from having or omitting HEAD tags.

Look, it's perfectly clear at any point in the HTML text whether this point belongs to HEAD or to BODY. The HEAD tags are irrelevant.

Google even recommends omitting them: http://code.google.com/speed/articles/optimizing-html.html

I agree with Shade. It's sub-optimal security for OpenID RPs to try grokking HTML in the first place. I'm sure if you tried everything

Of course parsing HTML is hell, but you have specified it.

"legal", you'd likely find dozens of ways that RPs are imperfect. But since delegation is a relatively rare scenario anyway (hundreds of millions of OpenIDs out there today, only a few actually delegate since it's an advanced user scenario) I think it's very reasonable to put a few restrictions on it so that RPs can be more secure and written more easily.

That doesn't change anything.

Everything you're saying is absolutely right. But it doesn't have anything to do with whether the HEAD element is surrounded by HEAD tags.

My example is *valid*, by the OpenID specification. I have placed LINK elements inside the HEAD element. That's what the OpenID spec demands.

The implementation is *buggy*. Yes, that's a fringe case. I can't really blame the author for not thinking about this.

And the spec is fine by itself but could be improved for the benefit of developers and users.

So there are several ways to handle it:

1. The status quo -- don't do anything: perfectly okay, but probably many more implementations will be buggy, without the developers even knowing about the pitfall.

2. making clear in the spec that the HEAD element does not necessarily correspond to HEAD tags and that a simple grep is *wrong*.

3. re-wording the spec so that it is clear that only a subset of HTML is supported, requiring the HEAD tag(s).

I'd prefer 2., just adding a non-normative note to the spec.

Thomas

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs