[OpenID] host-meta and "acct:"

Sat Nov 7 11:46:08 UTC 2009

PS: I would like to add to the point I was making earlier. I will give it a
different take.

To suggest that the "host" does not have a URI representing it is not the
same as saying the "host-meta" does not have a URI representing it.

The Subject of an XRD is a URI that resolves to its descriptor. (The XRD
Itself). eg.
<Subject>acct:john at example.com <acct%3Ajohn at example.com></Subject> //
Resolves to John's XRD
<Subject>http://example.com/john</Subject> // Also resolves to John's XRD in
case of his OpenID.

Question is why can't "what is good for the Goose also be good for the
Gander"?

<Subject>http://example.com/.well-known/host-meta</Subject> // Resolves to
the hosts XRD. So why not have this as the Subject of the XRD?

On Sat, Nov 7, 2009 at 3:09 PM, Santosh Rajan <santrajan at gmail.com> wrote:

> Quoting from
> http://tools.ietf.org/html/draft-nottingham-site-meta-01
>
> <http://tools.ietf.org/html/draft-nottingham-site-meta-01>
>
> "To address this, this memo proposes a single (and hopefully last)
>    "well-known location", /host-meta, which acts as a directory to the
>    interesting metadata about a particular authority."
>
>
> As you can see above the host-meta is "a directory to the meta-data on a
> host".
> And also this "directory" aka host-meta is also URI addressable. eg.
> http://example.com/.well-known/host-meta.
>
> Now can some one please explain to me how a URI addressable Resource CANNOT
> have a URI Subject?
>
>
> On Fri, Nov 6, 2009 at 11:12 PM, John Panzer <jpanzer at acm.org> wrote:
>
>> We have one compelling use case already where the existing <Subject>
>> doesn't work: host-meta is "about" a host, and there is no URI scheme to
>> represent Hosts (see IIW notes at
>> https://docs.google.com/a/johnpanzer.com/Doc?docid=0AZojn6fzr_tFZGRqNjhzcXZfOWY1cXA3emY5&hl=enfor alternatives considered). The simplest thing that anyone can come up
>> with for this use case that doesn't run into tripwires or pitfalls is a
>> separate element, <hm:Host>, that contains a hostname.
>>
>> Of course this element is only going to be recognized by host-meta-aware
>> processors.  And that's fine, because this is only valid for host-meta.  But
>> if XRD were required to have <Subject>, host-meta would be required to
>> define some "dummy" Subject to stick in there and it would be stupid.
>>
>> Now multiply this by N, where N is the number of things that may want to
>> leverage XRD.  I believe the least bad solution is to leave the XML
>> <Subject> element optional, while making it clear that there _is_ a
>> conceptual subject for every XRD.
>>
>> (I really wish we had left atom:id as a SHOULD instead of a MUST in Atom.
>>  We immediately turned around and discovered a use case where a required
>> atom:id causes problems and confusion -- creating new Atom entries via
>> POST.)
>>
>>
>> On Fri, Nov 6, 2009 at 8:12 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>
>>> Santosh,
>>>
>>> It is too bad that you couldn't make IIW.  I suspect we could have made
>>> better progress on understanding in person rather than iterating on the
>>> list.
>>>
>>> Yes it is better to air these issues before specs are finalized.
>>>
>>> At least in OASIS  that is why all of the TC work is done in public and
>>> we have strict rules about public review periods and and answering all
>>> formal feedback before a spec can go to a final vote of all the OASIS
>>> members.
>>>
>>> I am personally trying to devote more time to the IETF specs like
>>> WebFinger and LARDD that are profiling XRD so that I can better understand
>>> there reasons for wanting to use elements other than Subject.
>>>
>>> While I am currently of the opinion that Subject should not be required
>>> in the XRD spec, that shouldn't be taken that I don't have strong opinions
>>> about what happens in the profiles.
>>>
>>> They are however different discussions, and I need to be mindful of what
>>> hat I am wearing in what discussion.
>>>
>>> Regards
>>> John Bradley
>>>
>>> On 2009-11-06, at 7:54 AM, Santosh Rajan wrote:
>>>
>>> Hey John,
>>> I was just kidding Shade about the "+1". You can give any no of +1's to
>>> Shade and I couldn't agree with you more. I know you guys are working hard
>>> on this,and I have great respect for the work you are doing.
>>> It is just that I have a strong feeling that something has gone wrong
>>> somewhere. Things just don't look right to me. Especially when it comes to
>>> the "Subject" Element.
>>> Looking a the whole thing positively, it is better that these kinds of
>>> arguments happen at this stage (draft stage) than after the 1.0 release. I
>>> am sure you will agree with me on this.
>>> Thanks
>>> Santosh
>>>
>>>
>>> On Fri, Nov 6, 2009 at 9:11 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>>
>>>> I could give Shade another +1.
>>>>
>>>> I do think that he is clearly articulating the perspective of a majority
>>>> of people who donate there time to create specs like XRD.
>>>>
>>>> Some have said that our attempt to make XRDS too specific to the
>>>> requirements of XRI caused it to fork into XRDS-Simple.
>>>>
>>>> We are trying to learn from our past, along with the people who forked
>>>> XRD for legitimate reasons to accommodate there use case.
>>>>
>>>> We are attempting to produce a spec that can accommodate new things like
>>>> WebFinger without causing a fork in XRD every time  someone comes up with a
>>>> new idea they want to try out.
>>>>
>>>>  Profiles of XRD  will live or die based on there community adoption.
>>>>
>>>> Profiles of XRD are free to make Subject required.  Profiles of XRD can
>>>> define there own namespaces and extend XRD as they like.
>>>>
>>>> You can make formal comments through the OASIS feedback process if you
>>>> have a problem with that.
>>>>
>>>> We will consider all feedback before XRD is finalized.
>>>>
>>>> Regards
>>>> John Bradley
>>>> On 2009-11-06, at 7:19 AM, Santosh Rajan wrote:
>>>>
>>>> Hehe Shade, you are not going to get a "+1" for this one. Somebody did
>>>> give you one for an earlier post!
>>>>
>>>> On Fri, Nov 6, 2009 at 8:40 PM, SitG Admin <
>>>> sysadmin at shadowsinthegarden.com> wrote:
>>>>
>>>>> 3) XRD with <Host> instead of <Subject>
>>>>>>
>>>>>
>>>>> Hypothetical, but plausible, scenario:
>>>>>
>>>>> A developer realizes they need to indicate something different from
>>>>> Subject, but that they may need Subject later on. To avoid that future
>>>>> conflict (where they would find themselves forced to declare ActualSubject
>>>>> instead of just using Subject!), they use Host instead. Communicating this
>>>>> to the 3rd parties they deal with, and getting them to modify their own code
>>>>> to interop, is up to the developer :)
>>>>>
>>>>>
>>>>>  4) Someone might come along and decide lets have <Title> instead of
>>>>>> <Subject>
>>>>>>
>>>>>
>>>>> They won't get to make a unilateral decision, though. If they can't
>>>>> present compelling reasons why anyone ought to switch from using Subject to
>>>>> using Title, they'll probably be ignored ;)
>>>>>
>>>>>
>>>>>  5) Anyone can have anything else instead of <Subject>
>>>>>>
>>>>>
>>>>> If they want to, sure. How effective it is may depend on how many
>>>>> others they can get to accomodate their approach - and it may depend on how
>>>>> many others *don't*. Remember that security through obscurity actually
>>>>> *works*, in some cases; if they have an undocumented, hexadeximal-encoded,
>>>>> (weakly) encrypted Subject line labeled as another field, 99% of 3rd parties
>>>>> (having no reason to even *attempt* to figure out what Subject line IF ANY
>>>>> there is) will not pursue that any further.
>>>>>
>>>>>
>>>>>  Is this your idea of future compatibility?
>>>>>> Why is it so difficult for people to see that this whole thing is
>>>>>> leading to a mess?
>>>>>>
>>>>>
>>>>> We're blinded by this whole idea of "majority consensus".
>>>>>
>>>>> When you think that the majority's interests are in the actual
>>>>> *usefulness* of each spec, as defined by how many 3rd parties can be
>>>>> persuaded to practice the same methods (it's all about interoperability),
>>>>> your self-interest becomes self-limiting (it's all about enlightened
>>>>> self-interest): you don't want to exert too MUCH influence, making something
>>>>> perfect for YOU, because then it'll be too much trouble for everyone *else*
>>>>> (the Way of D'Shai is all about *balance*). The more accepting you can be of
>>>>> those who are different from you (it's all about tolerance), the more likely
>>>>> you are to receive cooperation instead of competition (Microsoft called this
>>>>> "Embrace and Extend"; pay it forward).
>>>>>
>>>>> -Shade
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://hi.im/santosh
>>>>
>>>>
>>>> _______________________________________________
>>>> general mailing list
>>>> general at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> http://hi.im/santosh
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>
>>>
>>
>
>
> --
> http://hi.im/santosh
>
>
>

-- 
http://hi.im/santosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091107/25c73fba/attachment.htm>