Typo section 8
Small typo in section 8 or draft 11: An association between the Relaying Parry and. I assume its Relaying Party. =eran ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Differentiating between User Identifier and OP Identifier
Thanks Johnny! It makes more sense now. Here are some further comments: I started to rewrite section 7 to make it easier to read but as I was going through it again and again, it became clearer. I think while all the terms are properly explained elsewhere, it might help to repeat some of them (like the two kinds of identifiers the user can provide) within the text. Here are some more specific comments and questions (I am not sure what's the process of suggesting changes to the draft). Obviously this is all meant as a suggestion so I will refrain from prefixing each comments with I would like to suggest (this might sound like a silly thing to say, but I really respect the work done by this group and would not want to offend anyone coming off too aggressive with instructions). Section 7.3.1: If more than one set of the following information has been discovered, the precedence rules defined in [XRI_Resolution_2.0] are to be applied. This somewhat confusing when combined with section 7.3.2.2: Once the Relaying Party has obtained an XRDS document, is MUST first search the document (following the rules described in [XRI_Resolution_2.0]) for an OP Identifier Element. My confusion comes from the fact the spec is not clear about what makes a valid XRDS document used for OpenID discovery. In this case, it sounds like an XRDS document MUST no include both an OP Endpoint element and a Claimed Identifier element. If it has both, and the Claimed Identifier Service Element has a higher priority, what does that mean? Remove section 7.3.2.2 and move its content to the end of 7.3.2. It makes a better introduction to the two possible elements and their relationship. Section 7.3.2.3 is confusing: 1. Does it only apply to XRI identifiers, not to XRDS documents found during Yadis discovery? 2. It seems to only apply to Claimed Identifier Element - maybe it should merge into section 7.3.2.1.2? 3. It would be helpful to explain or reference how the RP can confirm the authorities listed in the 2nd paragraph. I read a couple of long threads on this list regarding this, but did not see a resolution. 4. The first line of the third paragraph is not needed. 5. The section briefly explains the CanonicalID tag, but not the ProviderID tag. A one line context of the ProviderID tag would help. 6. Last line is confusing. Where would a CanonicalID come from if using a URL identifier? This entire section is under XRDS discovery. Does it refer to the URL used in a Yadis discovery (I assume not)? Section 7.3.2.4 says ...no longer used... but it is not clean where was it used before? The only spec I read prior this this one was the OpenID 1.1 which does not make use of XRDS documents. Move the first paragraph of section 7.3.3 to the end of section 7.3.1. It will explain which discovery process is used for each of the possible identity types. Also, from HTML-Based discovery MUST be supported by Relaying Parties is sounds like XRDS discovery is not required. If this is true, it should be made much clearer and provide guidelines of the proper reply to the user when the RP only supports HTML discovery. Thanks, =eran ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Using XRI Proxy Resolvers in OpenID discovery
Hi Eran,
Not sure I follow what the question is?
Should one use a proxy? Yes. Since it's unlikely any platform will support XRI
resolution natively. Should the proxy be used to grab an XRDS document? Yes, if
possible, and don't forget about the Accept: application/xrds+xml header
which a server may use to serve up such a document immediately. Parsing such a
document is not necessarily complex though - I found after implementing it in
PHP using SimpleXML that it's a lot less complex than the specification would
suggest.
I think it's a good idea to grab ALL the XRDS, and not just look for an OpenID
1.1/1.0 sub-element. In the case of failure to locate OpenID 1.1, you then have
the full document to see if it's only offering 2.0 (signon/server).
Given you need a full parsing ability, the first option seems to make the most
sense. Get as much as possible upfront to avoid any second/third HTTP requests
to the User/OP. It's more efficient this way I think - if you are using
caching, XRDS lookups shouldn't occur on each and every OpenID authentication
process anyway.
Regards,
Pádraic
Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com
- Original Message
From: Eran Hammer-Lahav [EMAIL PROTECTED]
To: specs@openid.net
Sent: Saturday, July 28, 2007 6:21:30 PM
Subject: Using XRI Proxy Resolvers in OpenID discovery
!--
_filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}
_filtered {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:Calibri,
sans-serif;}
a:link, span.MsoHyperlink
{color:blue;text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{margin:0in;margin-bottom:.0001pt;font-size:8.0pt;font-family:Tahoma,
sans-serif;}
span.EmailStyle17
{font-family:Calibri, sans-serif;color:windowtext;}
span.BalloonTextChar
{font-family:Tahoma, sans-serif;}
.MsoChpDefault
{}
_filtered {margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{}
--
The specification makes a suggestion (section 7.3 bullet 1)
to use a proxy for XRI resolution instead of implementing the XRI resolution
protocol in the Relaying Party. I am not clear as to what extent can / should
the
proxy be used for. For example, it can be used to turn ‘=eran’ into
an XRDS document:
http://xri.net/=eran?_xrd_r=application/xrds+xml
Or it can be used to retrieve an OpenID 1.0 service (BTW,
this does not work at xri.net) and save some effort in parsing an XRDS file:
http://xri.freexri.com/=eran?_xrd_r=application/xrd+xml_xrd_t=http%3a%2f%2fopenid.net%2fsignon%2f1.0
And last, it can be used to avoid XRI and XRDS altogether
(which I doubt is the intention –but one which might be suggested to RP
not implementing XRI if it is indeed optional):
http://xri.net/=eran
Which will redirect to an HTML page with OpenID tags
(assuming the RP doesn’t implement Yadis either).
However, when using the Yadis, the RP still has to have all
the logic of parsing a full XRDS file which can have multiple XRD elements,
multiple services with priority, and multiple URIs with priority (and append
instructions). Does that mean that proxies should only be used for the first
option?
=eran
Building a website is a piece of cake. Yahoo! Small Business gives you all the
tools to get online.
http://smallbusiness.yahoo.com/webhosting ___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
RE: Using XRI Proxy Resolvers in OpenID discovery
Thanks Pádraic, My question was in reference to the suggestion in the specification to use an XRI proxy and how it might relate to Relaying Party not implementing any XRI or Yadis support. The spec requires HTML discovery but not the other two, but users are expected to try their XRI identities not knowing what the RP will support. In other words, does the spec (or this group) support the idea of using an XRI proxy to convert an XRI to an HTML page via redirection to the XRI default page (XRI Resolution 2.0 section 7.6)? If the RP does not implement XRI (assuming the language of section 7.3.3 remains unchanged), should the spec recommend at least using an XRI proxy to fetch the default HTML page? EHL Ps. You dont have to use Accept: application/xrds+xml if you use query parameter _rds_r=application/xrds+xml From: Pádraic Brady [mailto:[EMAIL PROTECTED] Sent: Saturday, July 28, 2007 7:53 PM To: Eran Hammer-Lahav Cc: specs@openid.net Subject: Re: Using XRI Proxy Resolvers in OpenID discovery Hi Eran, Not sure I follow what the question is? Should one use a proxy? Yes. Since it's unlikely any platform will support XRI resolution natively. Should the proxy be used to grab an XRDS document? Yes, if possible, and don't forget about the Accept: application/xrds+xml header which a server may use to serve up such a document immediately. Parsing such a document is not necessarily complex though - I found after implementing it in PHP using SimpleXML that it's a lot less complex than the specification would suggest. I think it's a good idea to grab ALL the XRDS, and not just look for an OpenID 1.1/1.0 sub-element. In the case of failure to locate OpenID 1.1, you then have the full document to see if it's only offering 2.0 (signon/server). Given you need a full parsing ability, the first option seems to make the most sense. Get as much as possible upfront to avoid any second/third HTTP requests to the User/OP. It's more efficient this way I think - if you are using caching, XRDS lookups shouldn't occur on each and every OpenID authentication process anyway. Regards, Pádraic Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
