Sxip concerns with YADIS
Johannes Ernst
jernst+lists.danga.com at netmesh.us
Mon Dec 19 18:26:35 UTC 2005
Hi Dick,
On Dec 18, 2005, at 0:36, Dick Hardt wrote:
> Johannes
>
> Thanks for the response.
>
> I don't understand the user-driven vs service provider driven
> adoption point you make, nor how it relates to requiring two URLs.
Mental note to self/Joaquin/everybody: make sure that we explain this
well in the final YADIS 1.0 specification.
In the meantime, to get yourself up to speed on this subject, there's
been a lot of discussion around various aspects of this on this
mailing list over the months, although, as I recall, not always using
these terms.
> Yes, there are lots of XML parsers. Does not mean you need to use
> XML. HTML is a nice, structured format that is heavily used as well.
>
> I don't understand your fine-grained YADIS capabilities point either.
I gave you an example in my previous message; is there anything I can
clarify about my example?
> And the only thing that makes sense to be PULLed is data that
> someone wants to make public, but that is another debate.
>
> Summary: you have not convinced me that there are any advantages to
> the current spec (you can do everything you want to do given my
> suggestion), and I have pointed out several significant advantages.
Let's not be too hasty and let's not get into any "drive-by
architecture" mode because that tends to produce low-quality results
on a number of levels. I'm sure you'll agree.
I have the feeling it may be a bit premature to make this call given
what you said in the prior paragraphs of your message?
By the way, my intention has not been to convince you of anything.
The only people who can do that is yourself or people on your team.
I'm really only making two points:
- YADIS is an open effort by a variety of people from all over the
place, with the shared objective of making the many good innovations,
from many people in the user-controlled identity area interoperable
so they can build upon each other's work and help customers adopt it.
If SXIP is interested in contributing to that vision, my first point
is that the door is open for SXIP to become a contributor within the
same shared vision. (of course, if you decide you see no value in
that vision -- which is entirely up to you -- feel free to opt out!)
- We came up with the current baseline for YADIS based on many,
long discussions of a number of very well-qualified people who worked
hard to support a broad range of adoption scenarios and existing
technical architectures with what has turned out to be the same, very
simple protocol. I think we succeed quite well in that -- although
documentation is lagging, but we are working on that. The agreement
has been to implement this baseline (and a number of people have done
that already), to get to V1.0 as soon as possible, and if it turned
out after deployment that one of our tradeoffs was wrong, we'll fix
that in a V1.1 spec as soon as needed.
Does this make sense to you?
Cheers,
Johannes.
>
> -- Dick
>
>
> On 17-Dec-05, at 11:38 PM, Johannes Ernst wrote:
>
>> Dick,
>>
>> first: it's great that you are seriously looking at YADIS. Welcome
>> to YADIS!
>>
>> second: it's even better that you are looking at the currently
>> proposed protocols/formats, and that you are willing to provide
>> feedback on them. That keeps us honest and having additional
>> competent people, like yourself, critically review what we're up
>> to is definitely A Good Thing, regardless of whether any
>> particular suggestion will be adopted or not. Thank you!
>>
>> I think the issues you raise are valid ones, and they have been
>> discussed pretty exhaustively since Brad, David and myself
>> originally started meeting. The reasons why we came down to the
>> tradeoff -- because that's what it is -- that we came down to have
>> to do with the somewhat conflicting goals of enabling both user-
>> driven (passive service provider) and service-provider (passive
>> user) adoption. Note that in the best case scenario, only a single
>> HTTP GET is necessary, although you are correct in observing that
>> in practice during the early years of adoption, many times it will
>> have to be two GETs. (I realize that these scenarios are woefully
>> underdocumented at this point, and it's difficult for somebody
>> joining the discussion in the middle like yourself to get a
>> cohesive and complete picture right now of what those tradeoffs
>> were -- sorry about that, but we're working on it, and rest
>> assured that there are valid arguments behind those).
>>
>> Re XML parser, the first public YADIS draft actually used plain
>> text, not XML, but so many people were arguing convincingly that
>> all platforms have good XML parsers at this point and that we want
>> to develop a forward-looking standard, not a backward-looking one.
>> Hard to argue with that ;-), particularly given the beauty of
>> XPath for evaluating YADIS/XRDS documents.
>>
>> Re the very idea of fine-grained YADIS capabilities, of course we
>> think there's a need for it!! Without it, or something technically
>> equivalent, how could we, say, use OpenID authentication for the
>> client in a LID query for somebody's cell phone number? One of the
>> goals of YADIS is to let identity-related innovation occur on a
>> capability level rather than on a "vertically integrated identity
>> system" level, so that scenarios like this hybrid cell phone
>> number query are possible and commonplace. Our design principle
>> here is "small pieces loosely joined", rather than "big pieces
>> that need to be swallowed whole ..." While we've never talked
>> about this as far as I remember, I'd rather expect -- given that
>> the existing "big" standards for identity haven't been able to
>> meet so many people's needs, which of course is also the reason
>> d'être for SXIP -- that you'd agree with us on that one?
>>
>> Cheers,
>>
>>
>>
>> Johannes.
>>
>>
>>
>> On Dec 17, 2005, at 20:05, Dick Hardt wrote:
>>
>>>
>>> BACKGROUND:
>>>
>>> We spent some time looking at YADIS to see how a persona-url
>>> could support multiple identity protocols, specifically, how
>>> could someone have a persona-url that worked with SXIP and the
>>> protocols currently working with YADIS.
>>>
>>> We think that the blogosphere will likely be the source of many
>>> of the early adopters of an identity system, and that the URL of
>>> their blog is something they think of as being part of their
>>> identity, and is one of their personas. The URL is a unique
>>> identifier, and we call it a persona-url.
>>>
>>> The persona-url points to an HTML page that contains markup that
>>> allows an identity system to discover information about the
>>> persona. YADIS is about allowing Relying Partys (RP) to
>>> understand what protocol a persona-url supports.[1]
>>>
>>> The YADIS Capability Discovery Protocol [2] requires the persona-
>>> url to return either an HTML page that contains a link
>>> (capabilities-url) to an XRDS XML file , or an XRDS XML file
>>>
>>> Assuming the premise that most persona-urls will point to HTML
>>> pages, most of the time the RP will have to fetch two documents,
>>> and that *ALL* RPs will have to have an XML parser.
>>>
>>> ISSUES:
>>>
>>> 1) Performance
>>> - double the number of GETs for all HTML persona-urls
>>> - XML parsers take time to load and parse a file
>>>
>>> 2) Security
>>> - the user needs control over both the pesona-url AND the
>>> capabilities-url to secure their identity. Double the URLs,
>>> double the risk.
>>>
>>> 3) Implementation
>>> - all major web development platforms have high performance HTML
>>> parsers that present the document as a DOM. XML parsing is
>>> common, but is more complex than manipulating a DOM, and another
>>> thing for the developer to figure out.
>>> - getting two files requires more code, and more chances of
>>> something being broken
>>>
>>> SUGGESTION:
>>>
>>> We liked the way that OpenID worked earlier with a LINK tag in HTML:
>>>
>>> <link rel="openid.server" href="http://bob.com/openid-server.app" >
>>>
>>> We will have a LINK tag that looks something like this:
>>>
>>> <link rel="dix-homesite" href="http://homesite.com/sxip-
>>> server.app" class="dix:/core#1 dix://sxip.net/siple#1" >
>>>
>>> And think that LID could have a tag like this:
>>>
>>> <link rel="lid.capabilities" type="application/xrds+xml"
>>> href="http://myid.example.com/capabilities">
>>>
>>> Given that most protocols will have their own ways of describing
>>> what it can do, we don't see value in a common capability file.
>>>
>>>
>>> [1] http://yadis.org/wiki/Main_Page#What.27s_this_all_about.3F
>>>
>>> [2] http://yadis.org/wiki/Protocol
>>>
>>>
>>
>> Johannes Ernst
>> <lid.gif>
>> http://netmesh.info/jernst
>>
>>
>>
>
Johannes Ernst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20051219/a36db7e6/lid.gif
-------------- next part --------------
http://netmesh.info/jernst
More information about the yadis
mailing list