Yadis section in XRI Resolution spec (was RE: Writeup of XRDS Canonical ID verification for URLs and XRIs)
David, thanks, I have made the change. I renamed this thread to flag for anyone else that if they want to review the text being added to XRI Resolution 2.0 Working Draft 11 to incorporate the Yadis 1.0 spec, it is posted on the OASIS XRI TC wiki at: http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris Please let us know if you have any other feedback. =Drummond -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 4:09 PM To: =drummond.reed; Johnny Bufu Cc: specs@openid.net Subject: RE: Writeup of XRDS Canonical ID verification for URLs and XRIs That new wording for the Yadis bit looks good to me! -Original Message- From: =drummond.reed [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 4:49 PM To: 'Johnny Bufu' Cc: specs@openid.net; Recordon, David Subject: RE: Writeup of XRDS Canonical ID verification for URLs and XRIs >> On 13-Jun-07, at 7:04 PM, =drummond.reed wrote: >> >> With the Yadis specification now included in section 4 of XRI >> Resolution >> Working Draft 11 (see >> http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris >> for a copy >> of the text of this section -- thanks to David, Johnny, and Rowan for >> feedback on the first draft) > >Johnny Bufu wrote: > >Drummond, > >A bit more feedback on the Yadis section, hope you don't mind. Absolutely not. The goal has always been to make sure it specifies what Yadis 1.0 specifies. Everyone else who cares about URL-discovery-of-XRDS, please do review the proposed text of this section, posted on the XRI TC wiki at: http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris > The overview section (4.1) still says: > >> A service hosting an XRDS document discoverable through an HTTP(S) >> URI is only required to support one option > >Which is not equivalent with the Yadis spec, 6.2.4. Initiation: > >> This request MUST be either a GET or a HEAD request. > >Since the client has the option to do only GET (and the server is >required to respond), the server doesn't have a choice to support >only HEAD. GET is required , HEAD is optional (because of the >required fallback on the client side). Got it. It was David who sent me the suggestion to word it that way, as I think he thought that the client could do either option. David, if you agree with Johnny, then I will update the text of section 4.1 to say: "The protocol has two options: using an HTTP HEAD request to obtain a header with XRDS document location information (section 4.2), or using an HTTP GET request with content negotiation (section 4.3). A service hosting an XRDS document discoverable through an HTTP(S) URI MUST support the GET option, and MAY support the HEAD option. A client agent seeking to discover an XRDS document from an HTTP(S) URI MAY use either option, but MUST attempt the GET option if the HEAD option fails." Let me know if you have any feedback on this wording. >> extending Canonical ID verification to cover >> any combination of URLs and XRIs is quite straightforward. >> >> The formal proposal is now fully written up on the XRI TC wiki. The >> first >> link below is to the full page; the second takes you directly to >> the example >> section. >> >> http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification > >Looks ok to me. For the OpenID spec, it seems we have two options now: > >1) Use canonical IDs for URLs, and reference section 11 from the XRI >spec for the verification part > pros: > addresses recycling issue > brings in a (possibly) persistent identifier, addressing issue B) >here [1] > cons: > possible issue with defining the canonical ID (or an alternate >path) for HTML discovery > need to adjust how the claimed id is handled with Yadis discovery > more complex than 2) (more canonical id verification paths) > >2) Adopt the fragment proposal and specify it inline [2] > pros: > addresses recycling issue > simpler than 1) > cons: > does not address issue B here [1] > > >Johnny > > >[1] http://openid.net/pipermail/specs/2007-June/001847.html >[2] http://openid.net/pipermail/specs/2007-May/001767.html Agreed. Good analysis. The XRI TC had a good discussion about this extended Canonical ID verification model this morning, and we realized it actually adds some additional functionality even to XRI-to-XRI relationships. We didn't have time to complete the discussion, but we're going to proceed rapidly with the goal of incorporating it into ED03 next week. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Writeup of XRDS Canonical ID verification for URLs and XRIs
That new wording for the Yadis bit looks good to me! -Original Message- From: =drummond.reed [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 4:49 PM To: 'Johnny Bufu' Cc: specs@openid.net; Recordon, David Subject: RE: Writeup of XRDS Canonical ID verification for URLs and XRIs >> On 13-Jun-07, at 7:04 PM, =drummond.reed wrote: >> >> With the Yadis specification now included in section 4 of XRI >> Resolution >> Working Draft 11 (see >> http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris >> for a copy >> of the text of this section -- thanks to David, Johnny, and Rowan for >> feedback on the first draft) > >Johnny Bufu wrote: > >Drummond, > >A bit more feedback on the Yadis section, hope you don't mind. Absolutely not. The goal has always been to make sure it specifies what Yadis 1.0 specifies. Everyone else who cares about URL-discovery-of-XRDS, please do review the proposed text of this section, posted on the XRI TC wiki at: http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris > The overview section (4.1) still says: > >> A service hosting an XRDS document discoverable through an HTTP(S) >> URI is only required to support one option > >Which is not equivalent with the Yadis spec, 6.2.4. Initiation: > >> This request MUST be either a GET or a HEAD request. > >Since the client has the option to do only GET (and the server is >required to respond), the server doesn't have a choice to support >only HEAD. GET is required , HEAD is optional (because of the >required fallback on the client side). Got it. It was David who sent me the suggestion to word it that way, as I think he thought that the client could do either option. David, if you agree with Johnny, then I will update the text of section 4.1 to say: "The protocol has two options: using an HTTP HEAD request to obtain a header with XRDS document location information (section 4.2), or using an HTTP GET request with content negotiation (section 4.3). A service hosting an XRDS document discoverable through an HTTP(S) URI MUST support the GET option, and MAY support the HEAD option. A client agent seeking to discover an XRDS document from an HTTP(S) URI MAY use either option, but MUST attempt the GET option if the HEAD option fails." Let me know if you have any feedback on this wording. >> extending Canonical ID verification to cover >> any combination of URLs and XRIs is quite straightforward. >> >> The formal proposal is now fully written up on the XRI TC wiki. The >> first >> link below is to the full page; the second takes you directly to >> the example >> section. >> >> http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification > >Looks ok to me. For the OpenID spec, it seems we have two options now: > >1) Use canonical IDs for URLs, and reference section 11 from the XRI >spec for the verification part > pros: > addresses recycling issue > brings in a (possibly) persistent identifier, addressing issue B) >here [1] > cons: > possible issue with defining the canonical ID (or an alternate >path) for HTML discovery > need to adjust how the claimed id is handled with Yadis discovery > more complex than 2) (more canonical id verification paths) > >2) Adopt the fragment proposal and specify it inline [2] > pros: > addresses recycling issue > simpler than 1) > cons: > does not address issue B here [1] > > >Johnny > > >[1] http://openid.net/pipermail/specs/2007-June/001847.html >[2] http://openid.net/pipermail/specs/2007-May/001767.html Agreed. Good analysis. The XRI TC had a good discussion about this extended Canonical ID verification model this morning, and we realized it actually adds some additional functionality even to XRI-to-XRI relationships. We didn't have time to complete the discussion, but we're going to proceed rapidly with the goal of incorporating it into ED03 next week. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Writeup of XRDS Canonical ID verification for URLs and XRIs
>> On 13-Jun-07, at 7:04 PM, =drummond.reed wrote: >> >> With the Yadis specification now included in section 4 of XRI >> Resolution >> Working Draft 11 (see >> http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris >> for a copy >> of the text of this section -- thanks to David, Johnny, and Rowan for >> feedback on the first draft) > >Johnny Bufu wrote: > >Drummond, > >A bit more feedback on the Yadis section, hope you don't mind. Absolutely not. The goal has always been to make sure it specifies what Yadis 1.0 specifies. Everyone else who cares about URL-discovery-of-XRDS, please do review the proposed text of this section, posted on the XRI TC wiki at: http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris > The overview section (4.1) still says: > >> A service hosting an XRDS document discoverable through an HTTP(S) >> URI is only required to support one option > >Which is not equivalent with the Yadis spec, 6.2.4. Initiation: > >> This request MUST be either a GET or a HEAD request. > >Since the client has the option to do only GET (and the server is >required to respond), the server doesn't have a choice to support >only HEAD. GET is required , HEAD is optional (because of the >required fallback on the client side). Got it. It was David who sent me the suggestion to word it that way, as I think he thought that the client could do either option. David, if you agree with Johnny, then I will update the text of section 4.1 to say: "The protocol has two options: using an HTTP HEAD request to obtain a header with XRDS document location information (section 4.2), or using an HTTP GET request with content negotiation (section 4.3). A service hosting an XRDS document discoverable through an HTTP(S) URI MUST support the GET option, and MAY support the HEAD option. A client agent seeking to discover an XRDS document from an HTTP(S) URI MAY use either option, but MUST attempt the GET option if the HEAD option fails." Let me know if you have any feedback on this wording. >> extending Canonical ID verification to cover >> any combination of URLs and XRIs is quite straightforward. >> >> The formal proposal is now fully written up on the XRI TC wiki. The >> first >> link below is to the full page; the second takes you directly to >> the example >> section. >> >> http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification > >Looks ok to me. For the OpenID spec, it seems we have two options now: > >1) Use canonical IDs for URLs, and reference section 11 from the XRI >spec for the verification part > pros: > addresses recycling issue > brings in a (possibly) persistent identifier, addressing issue B) >here [1] > cons: > possible issue with defining the canonical ID (or an alternate >path) for HTML discovery > need to adjust how the claimed id is handled with Yadis discovery > more complex than 2) (more canonical id verification paths) > >2) Adopt the fragment proposal and specify it inline [2] > pros: > addresses recycling issue > simpler than 1) > cons: > does not address issue B here [1] > > >Johnny > > >[1] http://openid.net/pipermail/specs/2007-June/001847.html >[2] http://openid.net/pipermail/specs/2007-May/001767.html Agreed. Good analysis. The XRI TC had a good discussion about this extended Canonical ID verification model this morning, and we realized it actually adds some additional functionality even to XRI-to-XRI relationships. We didn't have time to complete the discussion, but we're going to proceed rapidly with the goal of incorporating it into ED03 next week. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Writeup of XRDS Canonical ID verification for URLs and XRIs
Drummond, On 13-Jun-07, at 7:04 PM, =drummond.reed wrote: > With the Yadis specification now included in section 4 of XRI > Resolution > Working Draft 11 (see > http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris > for a copy > of the text of this section -- thanks to David, Johnny, and Rowan for > feedback on the first draft) A bit more feedback on the Yadis section, hope you don't mind. The overview section (4.1) still says: > A service hosting an XRDS document discoverable through an HTTP(S) > URI is only required to support one option Which is not equivalent with the Yadis spec, 6.2.4. Initiation: > This request MUST be either a GET or a HEAD request. Since the client has the option to do only GET (and the server is required to respond), the server doesn't have a choice to support only HEAD. GET is required , HEAD is optional (because of the required fallback on the client side). > extending Canonical ID verification to cover > any combination of URLs and XRIs is quite straightforward. > > The formal proposal is now fully written up on the XRI TC wiki. The > first > link below is to the full page; the second takes you directly to > the example > section. > > http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification Looks ok to me. For the OpenID spec, it seems we have two options now: 1) Use canonical IDs for URLs, and reference section 11 from the XRI spec for the verification part pros: addresses recycling issue brings in a (possibly) persistent identifier, addressing issue B) here [1] cons: possible issue with defining the canonical ID (or an alternate path) for HTML discovery need to adjust how the claimed id is handled with Yadis discovery more complex than 2) (more canonical id verification paths) 2) Adopt the fragment proposal and specify it inline [2] pros: addresses recycling issue simpler than 1) cons: does not address issue B here [1] Johnny [1] http://openid.net/pipermail/specs/2007-June/001847.html [2] http://openid.net/pipermail/specs/2007-May/001767.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Writeup of XRDS Canonical ID verification for URLs and XRIs
>Dick Hardt wrote: > >Just to clarify, I do *not* propose we add support for multiple >identifiers in OpenID 2.0 -- but hope that this discussion sheds >light that there are other ways of solving the problem besides having >a permanent directory of identifiers aka the i-names/i-numbers >mechanisms. After discussion at IIW, and subsequently on this list last week, the OASIS XRI TC held a special telecon on Monday to discuss extending XRDS Canonical ID verification to URLs as well as XRIs. This approach addresses Dick's issue by enabling verification of any mapping of reassignable to canonical identifiers (URL-to-URL, URL-to-XRI, XRI-to-URL, XRI-to-XRI). In short, it would give OpenID users the same choice over their canonical identifier that they currently have over their claimed identifier. With the Yadis specification now included in section 4 of XRI Resolution Working Draft 11 (see http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris for a copy of the text of this section -- thanks to David, Johnny, and Rowan for feedback on the first draft), extending Canonical ID verification to cover any combination of URLs and XRIs is quite straightforward. The formal proposal is now fully written up on the XRI TC wiki. The first link below is to the full page; the second takes you directly to the example section. http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification http://wiki.oasis-open.org/xri/XriCd02/CanonicalIdVerification?action=show#h ead-a68aa13f6815124db6fbf909f172529e2783ae62 Feedback actively solicited -- further discussion is planned on the XRI TC telecon at 10AM Pacific tomorrow morning. If anyone would like to join that call, just send me email for an invitation. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
