2010/10/29 John Panzer <jpan...@google.com>: > 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?
Feel free to copy this to a wiki page: 1) Server-side requirements: - XRD/Webfinger: creating .well-known, placing a static host-meta file with appropriate content type, a Webfinger endpoint which could be static as well (e.g. by mapping to a file named like the account identifier) - SWD: creating .well-known, placing a dynamic endpoint which can parse the input (requested user and service) and return the output as one service from a list of services for the user 2) Server delegation: - XRD/Webfinger: host-meta can point to a third-party host for rel="lrdd" - SWD: defines its own delegation mechanism based on a JSON file 3) Authentication: - not fully defined but possible in both approaches via HTTP Basic authentication or OAuth 4) Consumer-side requirements: - XRD/Webfinger: fetching host-meta (preferrably with caching), parsing XML for lrdd endpoint; webfinger request, parsing XML for required service links - SWD: one request for user and service, parsing JSON for endpoint; multiple trips for multiple requests or if redirection is required 5) Network bandwidth requirements: - XRD/Webfinger: two requests (host-meta and lrdd), of which one is cacheable for multiple users (same domain); transmission of irrelevant data is very likely if XRDs are getting bigger - SWD: one request only, lightweight data; but can become inefficient if a longer list of services is fetched (individually) > 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? I've tried to include these thoughts in the compilation. Lukas _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
