OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] XRD trusted discovery workflow


Actually, this reminds me:

- I think email domain bootstrapping should also go through a resource map. The way your example works, you loose the username in the email. I would propose to treat bob@foo.com as the URI mailto:bob@foo.com and use your "URL Discovery bootstrapping" for it (I guess call it "URI Discovery bootstrapping" instead).

As for David's comment: If I remember EAUT correctly, it's a layer before any OpenID discovery would start, and would simply transform an email address into a URL (on which then to perform discovery). In fact, it is orthogonal to OpenID - you can use EAUT to transform an email address into a URL for all sorts of purposes, only one of which is OpenID discovery.

So putting a resource map as a direct child element of <XRD> and using that to get the meta data for the email URI would be equivalent to EAUT - putting the resource map inside the <Service> element of <Type> http://specs.openid.net/auth/2.0/server would not.

Now I don't know whether equivalence with EAUT is something to strive for here...

Dirk.

On Tue, Dec 9, 2008 at 9:08 PM, David Fuelling <david.fuelling@cordance.net> wrote:
On Wed, Dec 10, 2008 at 4:35 AM, Dirk Balfanz <balfanz@google.com> wrote:
- Having the URIMap element inside a Service element that also specifies a service type seems weird to me. It does have the advantage of being able to specify different resource maps for different service types, but somehow I always thought that there would be just one resource map (for XRD) for a site (perhaps from the days when I thought this would be in site-meta?). So I kinda expected something like <URIMap> as a direct child of the <XRD> element. I wonder what other people think about that.

Assuming I'm understanding things properly, the EAUT spec will use a <Service> element with a <URIMap> in order to indicate a site-wide policy for mapping an email address to a URL (on a site-wide basis).  Though, in its current form, the EAUT spec utilizes a <URI> element inside of a service, and the EAUT spec treats this as a URL template.  If URIMap is a valid element, then it seems like EAUT would want to use it, however.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]