Sxip concerns with YADIS

Sun Dec 18 07:38:01 UTC 2005

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
-------------- 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/20051217/a2dc110f/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst