Re: The State of the Hammer Discovery Stack

[Santosh Rajan]

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@...> 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@...) and we'll play traffic cop.

--
John Panzer / Google
jpanzer@... / abstractioneer.org / @jpanzer

_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs

--
http://hi.im/santosh



_______________________________________________
general mailing list
general@...
http://lists.openid.net/mailman/listinfo/openid-general

[Peter Williams]

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 <[e-mail]> 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 (
> [e-mail]) and we'll play traffic cop.
>
> --
> John Panzer / Google
> [e-mail] / abstractioneer.org / @jpanzer
>
>
> _______________________________________________
> specs mailing list
> [e-mail]
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


--
http://hi.im/santosh

_______________________________________________
general mailing list
[e-mail]
http://lists.openid.net/mailman/listinfo/openid-general


-----

Santosh Rajan
http://santrajan.blogspot.com