Re: Fallback flow for /site-meta for top level domains

I'd prefer to not have to define that would fall  
back to in an OpenID discovery spec as it  
doesn't feel like the right place to do it.  I'd also then hate to see  
a related spec such as OAuth discovery define this fall back in  
another manner.


On Dec 3, 2008, at 11:59 PM, Eran Hammer-Lahav wrote:

> > -----Original Message-----
> > From: Mark Nottingham []
> > Sent: Wednesday, December 03, 2008 7:35 PM
> > So, I see roughly three ways forward here;
> >
> > 1) We can explore expanding the scope of site-meta to be more like
> > 'domain-meta'.
> There is nothing in /site-meta (other than the somewhat vague name)  
> that prevent applications from specifying "domain" related links in  
> there. The only requirement is that they use appropriate 'rel'  
> values that will not cause confusion or "ignorant" user-agents to  
> fail. As long as the link record in the file is formatted correctly,  
> consuming applications can do with it as they like. Again, that is  
> as long as their way of using it doesn't break the common use cases  
> specified in the spec.
> > 2) In your specs, you can specify that when looking up the OpenID  
> for
> >
> > , the place to get site-meta is, falling back to
> >
> Assuming /site-meta supports a mechanism for listing a template- 
> based link relationship. That template with the appropriate 'rel'  
> will allow mapping a resource URI to its descriptor URI. Based on  
> the template language used, the vocabulary associated with the  
> template or 'rel' and any other application specific rules used, the  
> user-agent can construct the descriptor URI.
> How much of this is going to make it into the generic /site-meta  
> spec is very much up in the air at the moment. But either way, as  
> long as /site-meta does not prevent such an application, we can  
> specify this behavior directly in the XRD 1.0 spec, which hopefully  
> OpenID 2.x will adopt. And XRD is not going to care if the URI  
> scheme is mailto, http, or im. It will provide a mechanism to find  
> the desired map for that URI scheme with the appropriate vocabulary.
> This open question for this discussion on this list is really how  
> much of this should be supported by the generic /site-meta spec. I  
> would really like to hear from people without a stake in the OpenID/ 
> identity space. If there are no other use cases at the moment, it  
> will be hard for me to keep pushing for this in the /site-meta  
> proposal. But I am very much still committed to the overall  
> solution. OpenID is not going to reference /site-meta. It is going  
> to reference XRD 1.0, so it doesn't matter how this functionality  
> got into XRD 1.0 (via normative references to /site-meta or  
> specified locally).
> > 3) You can decide that site-meta isn't for you, and come up with  
> your
> > own thing.
> I would really like to avoid it. If /site-meta cannot accommodate  
> the use cases that got me involved in it to begin with, I do not see  
> much reason for me to be involved in it or have my name on it. But I  
> don't think we are at this point, and in fact, the current draft  
> without any changes already allows for this use case. It is more the  
> next text proposal that is lacking in that regard.
> > I'm concerned about #1, because it will likely involve things like
> > allowing discrimination between hostnames and schemes in site-meta
> > itself, as well as defining fallback behaviour, which will sacrifice
> > the simplicity that so many people are finding attractive. IME these
> > things take a lot of time to get right, and AIUI you don't have a  
> lot
> > of time.
> I am not sure what you mean by 'allowing discrimination between  
> hostnames and schemes'. Can you explain? The URI mapping use case  
> pretty much requires a scheme filter if the vocabulary is to include  
> anything other than 'uri'.
> I understand your reservation about the fallback scenario and my  
> position on this is that it is very much an OpenID specific issue  
> (not even an XRD issue) of how to normalize a user identifier (URL,  
> XRI, or email). Generic discovery should never make such assumptions  
> (that is equivalent to I raised the  
> issue because it came up and wanted people to discuss it and see if  
> there are other existing solutions to the problem.

Received on Wednesday, 24 December 2008 12:41:20 UTC