John is correct. Also when using a URL identifier like a blog it is possible to publish a XRD via link headers as well. That helps make publishing meta-data open to a broader selection of users.
If a site wanted to have a oAuth protected XRD service there is nothing to stop that. In XRI/XRDS resolution we had per service discovery, much the same as MS is proposing for similar reasons. People criticized that in XRI/XRDS as being too complicated. That is why it is not in the current XRD spec. We do need to make a side by side comparison. I know that people have asked for a JSON format XRD document option. That is on the OASIS TC list of things to work on. John Bradley On 2010-10-29, at 3:35 PM, John Panzer wrote: > I think that it would be good to have a writeup like this that describes the > differences and pros and cons of each approach. Perhaps on a Wiki page? > > Some random thoughts: > > One thing: host-meta is highly cacheable, so the # of round trips will > hopefully be comparable for large services with significant traffic. In fact > the user XRD is also cacheable as well so there can be zero round trips. > This proposal defines a mechanism separate from HTTP caching in order to > cache responses, it'd be good to have a rationale for doing that (and to have > an explanation of how this should interact with additional HTTP level > caching.) > > This mechanism appears to require multiple round trips to a server if you > want to discover multiple services. > > This proposal seems to require that the /well-known provider run a > significant service on their endpoint, as opposed to just dropping a file in > place. I think that the forwarding mechanism may be a way around that? How > would I hook into this mechanism if I really only can drop static files on my > web server, but I can perhaps use cloud services that I've registered with to > actually power the discovery? > > -- > John Panzer / Google > [email protected] / abstractioneer.org / @jpanzer > > > > On Fri, Oct 29, 2010 at 4:04 AM, Lukas Rosenstock <[email protected]> > wrote: > Hello! > This draft is looking nice, the idea and specification is simple and > straightforward. I would like to draw the connection to other > discovery approaches. > > The introductory example in the draft was this one: > GET > /.well-known/simple-web-discovery?principal=mailto:[email protected]&service=urn:adatum.com:calendar > HTTP/1.1 > > This returns the following response: > { > "locations":["http://calendars.proseware.com/calendars/joseph";] > } > > As per my understanding - please correct me if I'm wrong - this should > be semantically equivalent to the following: > 1) Perform host-meta discovery for example.com, which returns an XRD > with the webfinger endpoint. > 2) Do webfinger for [email protected]. > 3) The final XRD contains the following: > <XRD> > [...] > <Link rel="urn:adatum.com:calendar" > href="http://calendars.proseware.com/calendars/joseph"; /> > [...] > </XRD> > > Both approaches work, but SWD is a shortcut removes parsing > requirements and fetching roundtrips from the client. > > Thoughts, anyone?! > > Regards, > Lukas Rosenstock > > 2010/10/27 Mike Jones <[email protected]>: > > Yaron Goland and I are submitting this Simple Web Discovery (SWD) draft > > (attached and at > > http://self-issued.info/docs/draft-jones-simple-web-discovery-00.html) for > > consideration by the community to address this need. SWD is simple to > > understand and implement, enables different permissions to be applied to > > discovery of different services, and is JSON-based. I look forward to > > discussing this with many of you next week at IIW. > > > > > > > > -- Mike > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > Openid-specs-ab mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs-ab
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
