Manger, James H | 1 Jul 05:54 2008

[OpenID] Any use of <meta http-equiv="X-XRDS-Location" ...?

OpenIDers,

 

Does anyone in the OpenID community know of services that definitely need to use <meta http-equiv="X-XRDS-Location"…/>? For instance, services that cannot read or set HTTP headers, but still need to support XRDS discovery.

 

XRDS-Simple [xrds-simple.net] is a draft profile of XRDS.

One possible simplification is not requiring clients to parse an HTML response looking for

  <meta http-equiv="X-XRDS-Location" content=”…”/>

Instead, clients would only need to look for an X-XRDS-Location HTTP header or a Content-Type of application/xrds+xml.

Parsing HTML is not trivial so avoiding it could be worthwhile [§9.2 “Parsing HTML documents” takes almost 60 pages of the 500 page draft HTML5 spec http://www.whatwg.org/specs/web-apps/current-work/#parsing].

 

 

James Manger

 

From: xrds-simple <at> googlegroups.com [mailto:xrds-simple <at> googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, 1 July 2008 10:37 AM
To: xrds-simple <at> googlegroups.com

 

I think we need to post this question to the OpenID community as they are the primary users of this feature. I’ll do it later today if you don’t beat me to it (hint – please do).

From: Manger, James H
Sent: Tuesday, 1 July 2008 10:11 AM
To: 'xrds-simple <at> googlegroups.com'

 

Are there really going to be SPs that are sophisticated enough to support discovery, but so basic that they cannot set an X-XRDS-Location header or read an Accept header? I think you are setting the bar too low – at the cost of complicating every client (that now needs an HTML parser).

 

HTML parsing was originally based on SGML, but is now effectively its own language. The best specification of HTML parsing is http://www.whatwg.org/specs/web-apps/current-work/#parsing. “§9.2 Parsing HTML documents” takes almost 60 pages of this 500 page draft spec. My guess is that many apps using XRDS-Simple will not need an HTML parser for any other task – they will be designed for more precise syntaxes (XML, XHTML, JSON, Atom, key=value…). They are likely to look for a <meta http-equiv=…> element in various ad hoc ways (regular expressions, XHTML parser, HTML library, indexOf()…) that will mostly work but you can never be certain.

 

James Manger

From: xrds-simple <at> googlegroups.com [mailto:xrds-simple <at> googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, 1 July 2008 9:34 AM
To: xrds-simple <at> googlegroups.com

 

I think you went too far... :-)

But these are good points. The reason why HTML discovery is supported is to allow SPs without access to headers or accept requests to still be able to offer discovery. The reason why the second Accept is a SHOULD is because it doesn’t need to be a MUST given that it is for a resource that is only an XRDS document (must be).

The fragment text is to make it clear about the difference between the resource fragment and the location fragment. I’ll take a second look to see if I can simplify it.

From: xrds-simple <at> googlegroups.com [mailto:xrds-simple <at> googlegroups.com] On Behalf Of Manger, James H
Sent: Tuesday, 1 July 2008 9:26 AM
To: xrds-simple <at> googlegroups.com
Subject: [xrds-simple] Re: HEAD/GET precedence

 

Hi Eran,

 

The language can still be simplified.

 

  1. I would omit the sentence saying “retrieval is performed in two steps” as it might be 1 step (XRDS returned directly), or it might be more than 2 steps if there are redirects.

  2. I would omit the stuff about fragments as that is standard HTTP.

  3. I would omit the 1st sentence in 6.2 about checking the location against the endpoint. That would simply be a server error, which the client would notice after the next request anyway.

  4. Including “Accept: application/xrds+xml” is a MUST in 6.1 (unless the MUST only refers to the GET? Add another MUST to be clear), but only a SHOULD in 6.2. May as well make it MUST in both cases.

  5. Does anyone really need the <meta http-equiv=”…”/> option? That would be a good one to drop in the XRDS-Simple profile, particularly as parsing HTML is non-trivial (unless making some ad hoc simplifications) and quite different from parsing XML.

 

My revised suggestion:

 

6. Document Retrieval

 

On receiving a GET request with an Accept header listing application/xrds+xml, the server SHALL respond with:

  • The metadata document, delivered with a Content-Type of application/xrds+xml; or

  • An X-XRDS-Location header whose value is an absolute HTTP(S) URI of the metadata document.

The server may respond with HTTP redirects at any point.

 

Any fragment identifier in the URI that delivers the metadata document identifies an XML element with a matching xml:id attribute value.

 

James Manger

From: xrds-simple <at> googlegroups.com [mailto:xrds-simple <at> googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Saturday, 28 June 2008 8:54 AM
To: xrds-simple <at> googlegroups.com
Subject: [xrds-simple] Re: HEAD/GET precedence

 

Proposed language for draft 2:

---
6.  Document Retrieval

The Consumer obtains the Metadata Document by requesting the application/xrds+xml content type representation of the Resource. XRDS-Simple only defines a retrieval method for HTTP(S) Endpoints. While XRDS-Simple supports descriptions of non-HTTP(S) Endpoints, the method in which their associated Metadata Document is retrieved is beyond the scope of this specification.

Document retrieval is performed in two steps. First the document's location is obtained from the Endpoint, then the location obtained is used to request the Metadata Document.

6.1.  Obtaining Location

The Consumer MUST issue an HTTP(S) GET request to the Endpoint and include an Accept header specifying content type application/xrds+xml. If the Endpoint contains a fragment as defined by [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) section 3, it MUST be removed prior to making the request. The Service Provider response MUST be one of four options:

  • An HTTP redirect response with a Location header which the Consumer MUST follow by repeating the GET request with the provided URI.

  • A Content-Type header with value application/xrds+xml. In this case the response body is the Metadata Document and the workflow ends successfully skipping the step described in Section 6.2 (Requesting Document).

  • An X-XRDS-Location header where the value of the header MUST be an absolute HTTP(S) URI which gives the document's location.

  • A valid HTML document in the response body, with a <head> element that includes a <meta> element with an http-equiv attribute equals to X-XRDS-Location. The value of the <meta> element content attribute MUST be an absolute HTTP(S) URI which gives the document's location.


The Consumer MUST check the Service Provider's response for one of the four options in the order they are listed above, and MUST stop as soon as a match is found. If no match is found, the protocol fails and the discovery workflow ends unsuccessfully.

NOTE: The Consumer MAY attempt to issue an HTTP(S) HEAD request to the Endpoint specifying the content type prior to issuing the HTTP(S) GET request. If the Service Provider's response is a redirect, or includes the X-XRDS-Location header without a Content-Type header with value application/xrds+xml, the Consumer can skip the HTTP(S) GET request, otherwise will have to repeating both requests. Using the HEAD request is NOT RECOMMENDED unless the Consumer knows the Service Provider is likely to reply with a redirect response or an X-XRDS-Location header without a Content-Type header with value application/xrds+xml.

6.2.  Requesting Document

The Consumer SHOULD check if the document's location is identical to the Endpoint, excluding any differences in the URI fragments. If the URIs are considered identical, the discovery workflow ends unsuccessfully as that request has already failed to produce a valid XRDS-Simple document.

The Consumer MUST request the Metadata Document from the location URI using an HTTP(S) GET request and SHOULD include an Accept header specifying content type application/xrds+xml. The Consumer MUST follow any HTTP redirect responses received while requesting the Metadata Document.

The Service Provider MUST reply with a valid XRDS-Simple document in the response body. The Response SHOULD include the Content-Type header with value application/xrds+xml. If the response is not a valid XRDS-Simple document, the discovery workflow ends unsuccessfully.

If the document's location URI contains a fragment (not to be confused with an Endpoint fragment), it is used as an XRD identifier pointing to a specific XML element with an xml:id attribute of an identical value. The XRD identifier is described in Section 8.1 (XRD Identification).
---

I am not even sure we need to keep the HEAD protocol reference. HTTP defines how HEAD should work and this is really just a simple HEAD use cases. This text *does* change the discovery flow from XRI Resolution 2.0 in that it looks for the xrds content type header before the X-XRDS-Location header.

EHL


On 6/21/08 10:57 PM, "Eran Hammer-Lahav" <eran <at> hueniverse.com> wrote:



Reviewing my list of open issues for draft 2, I read this post a second time and tend to agree with James analysis in his first point.

Can any of the Yadis/OpenID authors explain why we have this inconsistency between GET and HEAD? If that can be resolved I would like to adopt the second suggestion.

EHL

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
Leon Kuunders | 1 Jul 09:55 2008

Re: [OpenID] OpenID and SSO

Nice discussion, but

Dick Hardt wrote:

> Presuming one of our objectives is to simplify the user experience of  
> logging into websites. From the users point of view, they  want to  
> login once and be done with it. This is the user view of SSO.

Methinks this premise is more likely to be: "a user would like to offer it's 
credentials once and be done with it."
Users do not want to login. Really, they don't.

Therefore you can measure the success of SSO by counting the dissapearing 
login "buttons" or "links" on websites who do offer user centric (profiling) 
services.
"Click to proceed", yes, "Login" no.

Regards, Leon
SitG Admin | 1 Jul 10:47 2008

Re: [OpenID] OpenID and SSO

>Users do not want to login. Really, they don't.
>
>Therefore you can measure the success of SSO by counting the dissapearing
>login "buttons" or "links" on websites who do offer user centric (profiling)
>services.

A vital question here, then, is whether the user values privacy 
enough to forgo this level of convenience. Short of opting to 
automatically grant all RP requests (and never prompt user for 
re-authentication to the OP - it can still expire, just don't bother 
the *user* with renewing it), there is no way to "intelligently" 
practice selective login for the user.

>"Click to proceed", yes,

There shouldn't even be that, though. Just go to the site and see the 
page. No matter how much you abstract the process of authenticating, 
if they have to take steps to have the service recognize them then 
it's a login.

-Shade
Hans Granqvist | 1 Jul 11:09 2008

Re: [OpenID] OpenID and SSO

>>"Click to proceed", yes,
>
> There shouldn't even be that, though. Just go to the site and see the
> page. No matter how much you abstract the process of authenticating,
> if they have to take steps to have the service recognize them then
> it's a login.

The entire idea of logging in is a bit of an anachronism. :)

The user should offer to automatically identify and authenticate, and
the RP acts on the credentials if it wants to.

There seems to be a way to do this with OpenID. You need to tweak it
just a bit. I wrote up my thoughts about this a while back:

http://commented.org/blog/2008/1/3/continuous-openid.html

Hans
Dick Hardt | 1 Jul 16:56 2008

Re: [OpenID] OpenID and SSO

I think the contractual and privacy issues will require a click to  
login. EU and Canadian privacy laws require the user to have consented  
to acquiring personal information. Similar to the EULA licenses users  
have to actively  do something with.

Since it is impossible to know how the user truly arrived at a page,  
and users can arrive at a page without having actively chose to, the  
site needs the user to actively do something to acknowledge they want  
to share information and  not be pseudonymous.

On 1-Jul-08, at 1:47 AM, SitG Admin wrote:

>> Users do not want to login. Really, they don't.
>>
>> Therefore you can measure the success of SSO by counting the  
>> dissapearing
>> login "buttons" or "links" on websites who do offer user centric  
>> (profiling)
>> services.
>
> A vital question here, then, is whether the user values privacy
> enough to forgo this level of convenience. Short of opting to
> automatically grant all RP requests (and never prompt user for
> re-authentication to the OP - it can still expire, just don't bother
> the *user* with renewing it), there is no way to "intelligently"
> practice selective login for the user.
>
>> "Click to proceed", yes,
>
> There shouldn't even be that, though. Just go to the site and see the
> page. No matter how much you abstract the process of authenticating,
> if they have to take steps to have the service recognize them then
> it's a login.
>
> -Shade
> _______________________________________________
> general mailing list
> general <at> openid.net
> http://openid.net/mailman/listinfo/general
SitG Admin | 1 Jul 17:55 2008

Re: [OpenID] OpenID and SSO

>http://commented.org/blog/2008/1/3/continuous-openid.html

You were envisioning something like a whitelist? If the user has to 
specify a site to assert their Identity to it, that's a (slightly 
different flow) login process :)

-Shade
David Recordon | 1 Jul 20:54 2008

Re: [OpenID] Any use of <meta http-equiv="X-XRDS-Location" ...?

The use case is less of a "service provider" but rather a normal user.  If I wanted to link to an XRDS-Simple document from http://www.davidrecordon.com/ it is far simpler for me to do so with a bit of HTML (which I can copy and paste) than by setting headers.  I think we've clearly seen this in terms of how popular OpenID Delegation is.

--David

On Jun 30, 2008, at 8:54 PM, Manger, James H wrote:

OpenIDers,

 

Does anyone in the OpenID community know of services that definitely need to use <meta http-equiv="X-XRDS-Location"…/>? For instance, services that cannot read or set HTTP headers, but still need to support XRDS discovery.

 

XRDS-Simple [xrds-simple.net] is a draft profile of XRDS.

One possible simplification is not requiring clients to parse an HTML response looking for

  <meta http-equiv="X-XRDS-Location" content=”…”/>

Instead, clients would only need to look for an X-XRDS-Location HTTP header or a Content-Type of application/xrds+xml.

Parsing HTML is not trivial so avoiding it could be worthwhile [§9.2 “Parsing HTML documents” takes almost 60 pages of the 500 page draft HTML5 spechttp://www.whatwg.org/specs/web-apps/current-work/#parsing].

 

 

James Manger

 

From: xrds-simple <at> googlegroups.com [mailto:xrds-simple <at> googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, 1 July 2008 10:37 AM
To: xrds-simple <at> googlegroups.com

 

I think we need to post this question to the OpenID community as they are the primary users of this feature. I’ll do it later today if you don’t beat me to it (hint – please do).

From: Manger, James H 
Sent: Tuesday, 1 July 2008 10:11 AM
To: 'xrds-simple <at> googlegroups.com'

 

Are there really going to be SPs that are sophisticated enough to support discovery, but so basic that they cannot set an X-XRDS-Location header or read an Accept header? I think you are setting the bar too low – at the cost of complicating every client (that now needs an HTML parser).

 

HTML parsing was originally based on SGML, but is now effectively its own language. The best specification of HTML parsing ishttp://www.whatwg.org/specs/web-apps/current-work/#parsing. “§9.2 Parsing HTML documents” takes almost 60 pages of this 500 page draft spec. My guess is that many apps using XRDS-Simple will not need an HTML parser for any other task – they will be designed for more precise syntaxes (XML, XHTML, JSON, Atom, key=value…). They are likely to look for a <meta http-equiv=…> element in various ad hoc ways (regular expressions, XHTML parser, HTML library, indexOf()…) that will mostly work but you can never be certain.

 

James Manger

From: xrds-simple <at> googlegroups.com [mailto:xrds-simple <at> googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, 1 July 2008 9:34 AM
To: xrds-simple <at> googlegroups.com

 

I think you went too far... :-)

But these are good points. The reason why HTML discovery is supported is to allow SPs without access to headers or accept requests to still be able to offer discovery. The reason why the second Accept is a SHOULD is because it doesn’t need to be a MUST given that it is for a resource that is only an XRDS document (must be).

The fragment text is to make it clear about the difference between the resource fragment and the location fragment. I’ll take a second look to see if I can simplify it.

From: xrds-simple <at> googlegroups.com [mailto:xrds-simple <at> googlegroups.com] On Behalf Of Manger, James H
Sent: Tuesday, 1 July 2008 9:26 AM
To: xrds-simple <at> googlegroups.com
Subject: [xrds-simple] Re: HEAD/GET precedence

 

Hi Eran,

 

The language can still be simplified.

 

  1. I would omit the sentence saying “retrieval is performed in two steps” as it might be 1 step (XRDS returned directly), or it might be more than 2 steps if there are redirects.

  2. I would omit the stuff about fragments as that is standard HTTP.

  3. I would omit the 1st sentence in 6.2 about checking the location against the endpoint. That would simply be a server error, which the client would notice after the next request anyway.

  4. Including “Accept: application/xrds+xml” is a MUST in 6.1 (unless the MUST only refers to the GET? Add another MUST to be clear), but only a SHOULD in 6.2. May as well make it MUST in both cases.

  5. Does anyone really need the <meta http-equiv=”…”/> option? That would be a good one to drop in the XRDS-Simple profile, particularly as parsing HTML is non-trivial (unless making some ad hoc simplifications) and quite different from parsing XML.

 

My revised suggestion:

 

6. Document Retrieval

 

On receiving a GET request with an Accept header listing application/xrds+xml, the server SHALL respond with:

  • The metadata document, delivered with a Content-Type of application/xrds+xml; or

  • An X-XRDS-Location header whose value is an absolute HTTP(S) URI of the metadata document.

The server may respond with HTTP redirects at any point.

 

Any fragment identifier in the URI that delivers the metadata document identifies an XML element with a matching xml:id attribute value.

 

James Manger

From: xrds-simple <at> googlegroups.com [mailto:xrds-simple <at> googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Saturday, 28 June 2008 8:54 AM
To: xrds-simple <at> googlegroups.com
Subject: [xrds-simple] Re: HEAD/GET precedence

 

Proposed language for draft 2:

---
6.  Document Retrieval

The Consumer obtains the Metadata Document by requesting the application/xrds+xml content type representation of the Resource. XRDS-Simple only defines a retrieval method for HTTP(S) Endpoints. While XRDS-Simple supports descriptions of non-HTTP(S) Endpoints, the method in which their associated Metadata Document is retrieved is beyond the scope of this specification. 

Document retrieval is performed in two steps. First the document's location is obtained from the Endpoint, then the location obtained is used to request the Metadata Document. 

6.1.  Obtaining Location

The Consumer MUST issue an HTTP(S) GET request to the Endpoint and include an Accept header specifying content type application/xrds+xml. If the Endpoint contains a fragment as defined by [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) section 3, it MUST be removed prior to making the request. The Service Provider response MUST be one of four options:

  • An HTTP redirect response with a Location header which the Consumer MUST follow by repeating the GET request with the provided URI.

  • A Content-Type header with value application/xrds+xml. In this case the response body is the Metadata Document and the workflow ends successfully skipping the step described in Section 6.2 (Requesting Document).

  • An X-XRDS-Location header where the value of the header MUST be an absolute HTTP(S) URI which gives the document's location.

  • A valid HTML document in the response body, with a <head> element that includes a <meta> element with an http-equiv attribute equals to X-XRDS-Location. The value of the <meta> element content attribute MUST be an absolute HTTP(S) URI which gives the document's location.


The Consumer MUST check the Service Provider's response for one of the four options in the order they are listed above, and MUST stop as soon as a match is found. If no match is found, the protocol fails and the discovery workflow ends unsuccessfully. 

NOTE: The Consumer MAY attempt to issue an HTTP(S) HEAD request to the Endpoint specifying the content type prior to issuing the HTTP(S) GET request. If the Service Provider's response is a redirect, or includes the X-XRDS-Location header without a Content-Type header with value application/xrds+xml, the Consumer can skip the HTTP(S) GET request, otherwise will have to repeating both requests. Using the HEAD request is NOT RECOMMENDED unless the Consumer knows the Service Provider is likely to reply with a redirect response or an X-XRDS-Location header without a Content-Type header with value application/xrds+xml. 

6.2.  Requesting Document

The Consumer SHOULD check if the document's location is identical to the Endpoint, excluding any differences in the URI fragments. If the URIs are considered identical, the discovery workflow ends unsuccessfully as that request has already failed to produce a valid XRDS-Simple document. 

The Consumer MUST request the Metadata Document from the location URI using an HTTP(S) GET request and SHOULD include an Accept header specifying content type application/xrds+xml. The Consumer MUST follow any HTTP redirect responses received while requesting the Metadata Document. 

The Service Provider MUST reply with a valid XRDS-Simple document in the response body. The Response SHOULD include the Content-Type header with value application/xrds+xml. If the response is not a valid XRDS-Simple document, the discovery workflow ends unsuccessfully. 

If the document's location URI contains a fragment (not to be confused with an Endpoint fragment), it is used as an XRD identifier pointing to a specific XML element with an xml:id attribute of an identical value. The XRD identifier is described in Section 8.1 (XRD Identification). 
---

I am not even sure we need to keep the HEAD protocol reference. HTTP defines how HEAD should work and this is really just a simple HEAD use cases. This text *does* change the discovery flow from XRI Resolution 2.0 in that it looks for the xrds content type header before the X-XRDS-Location header.

EHL


On 6/21/08 10:57 PM, "Eran Hammer-Lahav" <eran <at> hueniverse.com> wrote:



Reviewing my list of open issues for draft 2, I read this post a second time and tend to agree with James analysis in his first point.

Can any of the Yadis/OpenID authors explain why we have this inconsistency between GET and HEAD? If that can be resolved I would like to adopt the second suggestion.

EHL

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
Martin Atkins | 2 Jul 00:23 2008
Picon

Re: [OpenID] Any use of <meta http-equiv="X-XRDS-Location" ...?

Manger, James H wrote:
> 
> Parsing HTML is not trivial so avoiding it could be worthwhile [§9.2 
> “Parsing HTML documents” takes almost 60 pages of the 500 page draft 
> HTML5 spec http://www.whatwg.org/specs/web-apps/current-work/#parsing].
> 

While I've never really liked this fact, most OpenID implementations are 
far from HTML parsers and instead impose additional restrictions above 
and beyond what HTML requires, such as using an absolute URL (in 
OpenID's "link" as well as X-XRDS-Location), not supporting any entity 
escaping or numeric character references beyond the basic XML set, and 
accepting tags that would be considered by a full HTML parser to be 
commented out.

In an ideal world all of these things would use proper HTML parsers. If 
that's unrealistic, which I think it is, then I'd prefer it if these 
specs were more specific about how to extract the discovery tags so that 
implementations have better interop and so authors know what to watch 
out for. OpenID Authentication 2.0 is far from specific on how to 
extract the HTML discovery information; hopefully XRDS-Simple can do better.

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
John | 2 Jul 03:32 2008
Picon

Re: [OpenID] [xrds-simple] Any use of <meta http-equiv="X-XRDS-Location" ...?

Yes: Friend Connect is one example.

-John

On Jun 30, 2008, at 8:54 PM, "Manger, James H" <James.H.Manger <at> team.telstra.com> wrote:

OpenIDers,

 

Does anyone in the OpenID community know of services that definitely need to use <meta http-equiv="X-XRDS-Location"…/>? For instance, services that cannot read or set HTTP headers, but still need to support XRDS discovery.

 

XRDS-Simple [xrds-simple.net] is a draft profile of XRDS.

One possible simplification is not requiring clients to parse an HTML response looking for

  <meta http-equiv="X-XRDS-Location" content=”…”/>

Instead, clients would only need to look for an X-XRDS-Location HTTP header or a Content-Type of application/xrds+xml.

Parsing HTML is not trivial so avoiding it could be worthwhile [§9.2 “Parsing HTML documents” takes almost 60 pages of the 500 page draft HTML5 spec http://www.whatwg.org/specs/web-apps/current-work/#parsing].

 

 

James Manger

 

From: xrds-simple <at> googlegroups.com [mailto:xrds-simple <at> googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, 1 July 2008 10:37 AM
To: xrds-simple <at> googlegroups.com

 

I think we need to post this question to the OpenID community as they are the primary users of this feature. I’ll do it later today if you don’t beat me to it (hint – please do).

From: Manger, James H
Sent: Tuesday, 1 July 2008 10:11 AM
To: 'xrds-simple <at> googlegroups.com'

 

Are there really going to be SPs that are sophisticated enough to support discovery, but so basic that they cannot set an X-XRDS-Location header or read an Accept header? I think you are setting the bar too low – at the cost of complicating every client (that now needs an HTML parser).

 

HTML parsing was originally based on SGML, but is now effectively its own language. The best specification of HTML parsing is http://www.whatwg.org/specs/web-apps/current-work/#parsing. “§9.2 Parsing HTML documents” takes almost 60 pages of this 500 page draft spec. My guess is that many apps using XRDS-Simple will not need an HTML parser for any other task – they will be designed for more precise syntaxes (XML, XHTML, JSON, Atom, key=value…). They are likely to look for a <meta http-equiv=…> element in various ad hoc ways (regular expressions, XHTML parser, HTML library, indexOf()…) that will mostly work but you can never be certain.

 

James Manger

From: xrds-simple <at> googlegroups.com [mailto:xrds-simple <at> googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, 1 July 2008 9:34 AM
To: xrds-simple <at> googlegroups.com

 

I think you went too far... :-)

But these are good points. The reason why HTML discovery is supported is to allow SPs without access to headers or accept requests to still be able to offer discovery. The reason why the second Accept is a SHOULD is because it doesn’t need to be a MUST given that it is for a resource that is only an XRDS document (must be).

The fragment text is to make it clear about the difference between the resource fragment and the location fragment. I’ll take a second look to see if I can simplify it.

From: xrds-simple <at> googlegroups.com [mailto:xrds-simple <at> googlegroups.com] On Behalf Of Manger, James H
Sent: Tuesday, 1 July 2008 9:26 AM
To: xrds-simple <at> googlegroups.com
Subject: [xrds-simple] Re: HEAD/GET precedence

 

Hi Eran,

 

The language can still be simplified.

 

  1. I would omit the sentence saying “retrieval is performed in two steps” as it might be 1 step (XRDS returned directly), or it might be more than 2 steps if there are redirects.

  2. I would omit the stuff about fragments as that is standard HTTP.

  3. I would omit the 1st sentence in 6.2 about checking the location against the endpoint. That would simply be a server error, which the client would notice after the next request anyway.

  4. Including “Accept: application/xrds+xml” is a MUST in 6.1 (unless the MUST only refers to the GET? Add another MUST to be clear), but only a SHOULD in 6.2. May as well make it MUST in both cases.

  5. Does anyone really need the <meta http-equiv=”…”/> option? That would be a good one to drop in the XRDS-Simple profile, particularly as parsing HTML is non-trivial (unless making some ad hoc simplifications) and quite different from parsing XML.

 

My revised suggestion:

 

6. Document Retrieval

 

On receiving a GET request with an Accept header listing application/xrds+xml, the server SHALL respond with:

  • The metadata document, delivered with a Content-Type of application/xrds+xml; or

  • An X-XRDS-Location header whose value is an absolute HTTP(S) URI of the metadata document.

The server may respond with HTTP redirects at any point.

 

Any fragment identifier in the URI that delivers the metadata document identifies an XML element with a matching xml:id attribute value.

 

James Manger

From: xrds-simple <at> googlegroups.com [mailto:xrds-simple <at> googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Saturday, 28 June 2008 8:54 AM
To: xrds-simple <at> googlegroups.com
Subject: [xrds-simple] Re: HEAD/GET precedence

 

Proposed language for draft 2:

---
6.  Document Retrieval

The Consumer obtains the Metadata Document by requesting the application/xrds+xml content type representation of the Resource. XRDS-Simple only defines a retrieval method for HTTP(S) Endpoints. While XRDS-Simple supports descriptions of non-HTTP(S) Endpoints, the method in which their associated Metadata Document is retrieved is beyond the scope of this specification.

Document retrieval is performed in two steps. First the document's location is obtained from the Endpoint, then the location obtained is used to request the Metadata Document.

6.1.  Obtaining Location

The Consumer MUST issue an HTTP(S) GET request to the Endpoint and include an Accept header specifying content type application/xrds+xml. If the Endpoint contains a fragment as defined by [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) section 3, it MUST be removed prior to making the request. The Service Provider response MUST be one of four options:

  • An HTTP redirect response with a Location header which the Consumer MUST follow by repeating the GET request with the provided URI.

  • A Content-Type header with value application/xrds+xml. In this case the response body is the Metadata Document and the workflow ends successfully skipping the step described in Section 6.2 (Requesting Document).

  • An X-XRDS-Location header where the value of the header MUST be an absolute HTTP(S) URI which gives the document's location.

  • A valid HTML document in the response body, with a <head> element that includes a <meta> element with an http-equiv attribute equals to X-XRDS-Location. The value of the <meta> element content attribute MUST be an absolute HTTP(S) URI which gives the document's location.


The Consumer MUST check the Service Provider's response for one of the four options in the order they are listed above, and MUST stop as soon as a match is found. If no match is found, the protocol fails and the discovery workflow ends unsuccessfully.

NOTE: The Consumer MAY attempt to issue an HTTP(S) HEAD request to the Endpoint specifying the content type prior to issuing the HTTP(S) GET request. If the Service Provider's response is a redirect, or includes the X-XRDS-Location header without a Content-Type header with value application/xrds+xml, the Consumer can skip the HTTP(S) GET request, otherwise will have to repeating both requests. Using the HEAD request is NOT RECOMMENDED unless the Consumer knows the Service Provider is likely to reply with a redirect response or an X-XRDS-Location header without a Content-Type header with value application/xrds+xml.

6.2.  Requesting Document

The Consumer SHOULD check if the document's location is identical to the Endpoint, excluding any differences in the URI fragments. If the URIs are considered identical, the discovery workflow ends unsuccessfully as that request has already failed to produce a valid XRDS-Simple document.

The Consumer MUST request the Metadata Document from the location URI using an HTTP(S) GET request and SHOULD include an Accept header specifying content type application/xrds+xml. The Consumer MUST follow any HTTP redirect responses received while requesting the Metadata Document.

The Service Provider MUST reply with a valid XRDS-Simple document in the response body. The Response SHOULD include the Content-Type header with value application/xrds+xml. If the response is not a valid XRDS-Simple document, the discovery workflow ends unsuccessfully.

If the document's location URI contains a fragment (not to be confused with an Endpoint fragment), it is used as an XRD identifier pointing to a specific XML element with an xml:id attribute of an identical value. The XRD identifier is described in Section 8.1 (XRD Identification).
---

I am not even sure we need to keep the HEAD protocol reference. HTTP defines how HEAD should work and this is really just a simple HEAD use cases. This text *does* change the discovery flow from XRI Resolution 2.0 in that it looks for the xrds content type header before the X-XRDS-Location header.

EHL


On 6/21/08 10:57 PM, "Eran Hammer-Lahav" <eran <at> hueniverse.com> wrote:



Reviewing my list of open issues for draft 2, I read this post a second time and tend to agree with James analysis in his first point.

Can any of the Yadis/OpenID authors explain why we have this inconsistency between GET and HEAD? If that can be resolved I would like to adopt the second suggestion.

EHL


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "XRDS-Simple" group.
To post to this group, send email to xrds-simple <at> googlegroups.com
To unsubscribe from this group, send email to xrds-simple-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/xrds-simple?hl=en
-~----------~----~----~----~------~----~------~--~---

uot; group.
To post to this group, send email to xrds-simple <at> googlegroups.com
To unsubscribe from this group, send email to xrds-simple-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/xrds-simple?hl=en
-~----------~----~----~----~------~----~------~--~---

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
Leon Kuunders | 2 Jul 09:58 2008

Re: [OpenID] OpenID and SSO

Think about IP addresses: are they personal information? If so, and 
following the train of thought mentioned by Dick, a user would not be 
able to choose to share information without sharing this information.

So I guess this discussion comes down to the difference between logging 
in (offer credentials) and profiling (offer personal information).  
These two can, but do not have to be, the same: credentials are not 
necessary personal information.

"Click to proceed" would result in "profiling", not "authentication", 
so  SSO can be invisible to the user.

my 2$, --Leon.

Dick Hardt wrote:

> I think the contractual and privacy issues will require a click to 
> login. EU and Canadian privacy laws require the user to have consented 
> to acquiring personal information. Similar to the EULA licenses users 
> have to actively  do something with.
>
> Since it is impossible to know how the user truly arrived at a page, 
> and users can arrive at a page without having actively chose to, the 
> site needs the user to actively do something to acknowledge they want 
> to share information and  not be pseudonymous.
>
> On 1-Jul-08, at 1:47 AM, SitG Admin wrote:
>
>>> Users do not want to login. Really, they don't.
>>>
>>> Therefore you can measure the success of SSO by counting the 
>>> dissapearing
>>> login "buttons" or "links" on websites who do offer user centric 
>>> (profiling)
>>> services.
>>
>> A vital question here, then, is whether the user values privacy
>> enough to forgo this level of convenience. Short of opting to
>> automatically grant all RP requests (and never prompt user for
>> re-authentication to the OP - it can still expire, just don't bother
>> the *user* with renewing it), there is no way to "intelligently"
>> practice selective login for the user.
>>
>>> "Click to proceed", yes,
>>
>> There shouldn't even be that, though. Just go to the site and see the
>> page. No matter how much you abstract the process of authenticating,
>> if they have to take steps to have the service recognize them then
>> it's a login.
>>
>> -Shade
>> _______________________________________________
>> general mailing list
>> general <at> openid.net
>> http://openid.net/mailman/listinfo/general
>
>

Gmane