The Hammer-Stack
Who: Blaine, John Panzer, Breno (just one name, like Cher), Eran Hammer-Lahav, Dirk Balfanz, Will Norris, Eran Sandler, Jared Hanson, Allen Tom, ... et al
Problem: Go through open list of issues for the Hammer Stack and decide where to go. Host-meta, Webfinger, L(A)RDD.
Open Issues:
Subject of Host-Meta EHL: XRD has a Subject element (string). XRD may be subject-less. People getting XRD must know what subject is about. Easiest way is to use a URI for the subject. So anything you can make a valid URI for. 3 proposals:
- Just give it a URI, if you want to use Subject you need to invent some way to use a URI (urn, tag, blah blah)
- Just make it a string, add an attribute that indicates the type of string (URI or ???). Moves war into attribute.
- Just allow a new extension element (in its own namespace) to use instead of Subject if Subject isn't doing it for you.
EHL: Tried hard to find a URI for Host-Meta specifically. Tried host:, dns:, a whole bunch. Only real 2 options are using a "well known URI recipe" e.g., http://host-meta.net/<domainname>. Could use SemWeb hash approach. Could mint a URN in our own namespace. Current thinking is to use "scope" instead of Subject for host-meta (next topic)
Scope of Host-Meta
Define host as hostname. One host-meta needs to support more than one hostname. Proposal: Need to use a unique host-meta document w/unique scope for each RFC3986 domain-or-ip-address.
<hm:Host>example.com</hm:Host>
Q: How to discover public key used for signing? (Undefined by Host-Meta spec... many ways.)
Q: Harder to get wildcard certs ($300 vs. $20), could allow alternate names with Host and HostAlias? (Need a trust discussion.)
RESOLVED: Use single RFC3986 hostname w/syntax as above (namespaced <Host> element).
Host-Meta Template Vocabulary and Syntax
Current draft of URI templates being worked on, will be >1yr before published as RFC, 3-4 months before stable draft. Want to make sure host-meta's approach works with more extensive syntax for URI templates. Defined default template syntax -- can define others dependent on custom rel values. Syntax takes curly bracket {var} with {+var} meaning don't encode reserved characters. (See spec for details.)
Everything works with URIs (not IRIs) so it's been converted from an IRI to a URI using RFC 3987 before this spec kicks in.
List of vars allowed in host-meta templates: "uri", "scheme", "authority", "host", "port", "userinfo", "fragment", "path", "query"
Approaches:
- Just use "uri" alone, and let redirects handle more complicated transformations. PRO: Simple. CON: Means additional redirect to handle common cases that are pretty standard/simple string swizzling.
RECOMMENDED: Just use {uri}, {+uri}
New Approach for L(A)RDD
EHL: Originally, LRDD took building blocks of host-meta etc. to replace YADIS. Started with that, feedback from W3C TAG, others to make it more generic so it'd work for other use cases beyond OpenID. The more generic the less of a normative spec and the more recipe for a protocol. So now site-meta is know well-known, the building blocks are there to build a generic discovery spec. Thinking: LaRDD is about how to get "the LaRDD XRD" for a resource. 3 profiles: (HF) Host-first, then Resource (Link, etc.); (RF) Resource-first, then Host.
... (Lunch. Lots of discussion back and forth about HF vs. RF and security/flexibility implications.)
Breno: Parsing HTML makes things slow and more brittle. Just using Link: header cuts out some users from embedding links.
All agree 1 LaRDD priority order is preferable to multiple (willing to compromise on favorite order to achieve this)
Blaine: If we use HostFirst, spec will be ignored.
Summary: Lots of support for resource-first, lots of good points back and forth, security folks support host-first. Interesting proposal (host first, but host-meta has optional "let resource links override if present") which may be a Grand Compromise or not. Clearly needs more discussion on list.
(At least we killed "Don't Care" and "Protocol Dependent" options.)
---
Rel values: Either have one rel value to discover XRD per protocol, or just one that is for L(a)RDD and then everybody uses that. Everybody is currently assuming a canonical XRD for a resource (OpenID, Webfinger, Salmon, ...).
Point: Can there be more than one signing authority? LaRDD can provide default even if some protocols add more rel values. Should LaRDD provide a default rel value ("describedby") or not?
(Lots of back and forth and levels of indirection. Break to go find a room with a whiteboard.)
Diagram: URI -> <Link>, Link:, or Host-Meta -> XRD URI
Example: URI x in Apps for Your Domain, Google is OP. Let's say use Host-Meta. Points at XRD for specifically x, which includes links off to OpenID endpoints etc.
Example/Use Case: http://example.com/bob, outsources OP to Google, PoCo endpoint to Plaxo. How?
Concept: example.com/.well-known/host-meta contains pointers wi/rel values pointing at Google and Plaxo (EHL: Wrong architecture!) EHL: host-meta contains just a pointer to "XRD" per resource.
host-meta contains <Link><Rel>LRDD</Rel><URLTemplate>blah blah {+url}</URLTemplate></Link>, and the template points at an XRD that itself points at Google and Plaxo.
...
Webfinger result document == XRD for the acct: URI. (That then points at other stuff.) Webfinger is a special case of LRDD. May want a different profile server for Web?
Common hosting situation: Delegate profile hosting. e.g., btinternet.com points over to Google or Yahoo!. But, don't want Google or Yahoo! to be authoritative for non-acct: URIs for btinternet.com. Let's say acct: URIs are all delegated to Yahoo!. btinternet.com hosted XRD service that does a 301 redirect over to Yahoo! if acct:, returns XRD content if not. OK DONE.
Question from Blaine that will hopefully clarify things: I get one host-meta document, and XRD, with multiple links with same rel, both fetched and each of those have links to 2 more XRD documents each. Is the XRD for the URI I'm trying to resolve the union of all these? Or something else? (A: No on the first.)
host-meta describes the HOST. uses XRD as a format. LARDD document describes the RESOURCE. uses XRD as a format also. Webfinger is a specialization of LARDD that handles acct: URIs ("How You Use LARDD to resolve acct: URIs")
..and the use of URI Templates in an XRD obtained for a RESOURCE is undefined at this time. (Could be defined if desired.)
Breno: We have to be able to tell domain owners to publish a signed XRD file, with templates, _once_ to handle their entire population of users (to say, for example, that the OpenID endpoint can be found over at Yahoo! or Google) -- trying to get them to dynamically sign thousands or millions of user-XRD documents
RESOLVED:
Webfinger - syntax of acct: URI Webfinger - rel value Generalized Discovery for URIs Rel value for xrd-edit URL (a way to discover how to add services? go to web page?)
