[OpenID] The State of the Hammer Discovery Stack

Sun Nov 8 02:37:23 UTC 2009

I had the benefit of being there...

It felt good

it rebuilt x400/x500 using the web - same concept, modern conceptions.

For me, I had a turning point for openid.next when I read the salmon spec.

Ok. Now I get it - and Peter, you can  stop worrying about the demise of
uci. The following act is bigger and better. Uci was but a stepping stone.

Secure messaging between walls, discovery of keys and endpoints, self
certification based trust models, cloud based signing and card selectors,
cloud offloading of endpoints, all driven by the primordial need to be
consumable and usable - by the average Joe.

it was like the ldap moment (which translated the impenetrable, experts only
world of x500 into ldap (and  wonder known as activedirectory). In fact it
went back in time, revisiting the Netscape dec

Santosh Rajan wrote:
> 
> This whole thing looks like the "Hammer'd Stack" to me. I am not alluding
> to
> Mr Hammer himself. Rather to all the people involved in the development of
> this Stack.
> 
> I thought the IIW would have put some sense into all you guys heads.
> Instead
> things are getting wierd and  wilder by the day,after the IIW. I
> sincererly
> hope we don't reach the bizarre. I have been posting all my arguments at
> the
> OpenID forum if you are interested in reading them. Coming from a
> potential
> consumer of your spec rather than a peer, it might do good for you guys to
> read those comments.
> 
> The whole thing looks like, "too many cooks spoiling the broth" and "a
> camel
> is a horse designed by a committee".
> 
> I have a solution for the problem. We must send Mr Hammer to a remote
> island, with no communication to the rest of the world, for a period of
> one
> month, with a mandate to come out with a new Hammer Stack, paid for by the
> OIDF (I have copied this to OIDF). I am sure he will come up with a
> fantastic spec.
> 
> 
> On Sat, Nov 7, 2009 at 1:11 AM, John Panzer <jpanzer at google.com> wrote:
> 
>> All (and I do mean all, I've pulled in a lot of related lists, so please
>> be
>> selective in replies to this email):
>>
>> At IIW this week, there was a spontaneous marathon session about nailing
>> down open issues around discovery (which Webfinger depends on and is
>> helping
>> to drive).  The notes from the discussion are available at
>> https://docs.google.com/a/johnpanzer.com/Doc?docid=0AZojn6fzr_tFZGRqNjhzcXZfOWY1cXA3emY5&hl=en.
>>  A  lot of people were there, my estimate as 20+ at one point.
>>
>> Since the Hammer Discovery Stack encompasses no fewer than 6 independent
>> standards, there is no one mailing list to go to in order to discuss the
>> whole thing top to bottom.  I suggest the Webfinger mailing list as a
>> place
>> to talk about all of the pieces together.  First off, I'm going to draw a
>> box around the whole stack (L(a)RDD, XRD, host-meta, Webfinger,
>> .well-known,
>> Web Linking).  The consensus at IIW was that this was the "Hammer
>> Discovery
>> Stack" so that's what I'll call it (see
>> http://www.flickr.com/photos/57287692@N00/4081200654/).
>>
>> So, what's the state of the Hammer Discovery Stack?  I'll try to capture
>> *the
>> consensus of the sub-group at IIW* below.  Note that these all need to be
>> ratified by the various standards groups for doing the various bits of
>> the
>> Stack.
>>
>> 1. HDS needs the .well-known/host-meta XRD file to be able to indicate
>> what
>> "host" it's talking about.  *RESOLVED*: <hm:Host>example.com</hm:Host>,
>> no
>> Subject, contents of hm:Host to be RFC 3986 "Host" string.
>>
>> 2. HDS needs a simple URI template syntax for template XRD files (XRD
>> files
>> that contain recipes for URIs rather than actual URIs).  It also needs a
>> vocabulary, e.g., what variable names does HDS require? *RESOLVED*:  Use
>> {uri} and {+uri}.  These are forward-compatible with RFCs that are
>> in-the-works but don't depend on to-be-minted RFCs.  We use one variable,
>> "uri", no sub-parts.
>>
>> 3. HDS (via L(a)RDD) needs to define what priority to use when doing
>> discovery between Link: header, various resource-specific link elements,
>> and
>> host-meta.  This comes down to one question:  Should HDS prioritize *
>> host-first* discovery, meaning that if host-meta exists it has the final
>> word, or should it prioritize *resource-first* discovery, meaning that if
>> Link: header or <link> element exists it has the final word?  *RESOLVED*:
>>  There Can Be Only One; everyone agreed that there must be one priority
>> order, it cannot be left undefined or optional, and everyone was willing
>> to
>> give up their favorite ordering in order to standardize on just one. 
>> *NOT
>> RESOLVED*:  Exactly which of host-first or resource-first we should pick.
>>  (I plan to start a separate thread for this topic.)
>>
>> 4. We also discovered that the HDS does not currently define what it
>> means
>> to have a template {uri} inside anything other than a host-meta XRD. 
>> This
>> is because the spec writers didn't have a use case for this.  Breno has a
>> use case for this, and believes that signed XRDs for individual resources
>> are only going to be deployable in many situations if you can sign a
>> template rather than having to dynamically sign millions of individual
>> XRD
>> representations.  *RESOLVED*:  To solve this, *Breno* needs to write up a
>> proposal for the semantics and get it adopted by the HDS (somewhere).
>>
>> RAN OUT OF TIME/COFFEE, NO DISCUSSION:
>> *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?)*
>>
>> Please follow up on individual issues by starting or contributing to
>> threads in the appropriate spec discussion lists.  If you can't figure
>> out
>> what that is for one or more issue, please start with the webfinger list
>> (
>> webfinger at googlegroups.com) and we'll play traffic cop.
>>
>> --
>> John Panzer / Google
>> jpanzer at google.com / abstractioneer.org / @jpanzer
>>
>>
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
> 
> 
> -- 
> http://hi.im/santosh
> 
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
> 
> 
> -----
> 
> Santosh Rajan
> http://santrajan.blogspot.com 
> 

-- 
View this message in context: http://old.nabble.com/Re%3A-The-State-of-the-Hammer-Discovery-Stack-tp26245634p26250544.html
Sent from the OpenID - General mailing list archive at Nabble.com.