RE: Writeup of XRDS Canonical ID verification for URLs and XRIs

2007-06-14 Thread Recordon, David
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


Writeup of XRDS Canonical ID verification for URLs and XRIs

2007-06-13 Thread =drummond.reed
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