[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] xml dsig profile
On Thu, Mar 12, 2009 at 9:36 PM, Nat Sakimura <n-sakimura@nri.co.jp> wrote: > OK. I did not spell out my question well enough. > > 1) Did you reach a consensus on this XML Sig with simplified c14n way of > doing? Enough consensus to start experimenting. =) Once we've got a couple of working implementations we should step back and see what we like and what we don't. (BTW: the step2 project is hosted at code.google.com, there is a mailing list, there is code, everyone, please come contribute. =) > 2) Does it mean that you gave up the multiple XRDs with different > authorities signing them? So I've heard two different use cases for this. Use case #1: let one authority add a signed entry to a user's XRD. The only example use case I've heard involved significant risk of fraud, and the only way to prevent the fraud would be to *check back* with the authority. At which point the added security value of having the signed entry in the user's XRD vanished. It makes more sense to think of an authority publishing some advisory information in a user's XRD. e.g. "this user pays for service X at provider Y, and go to Z for more information". Use case #2: do a bunch of discovery operations and get a bunch of XRDs, then combine them into a single XML document. I don't understand this use case, but I don't really object to it either. It's still possible, using the "inline mode" described here: http://wiki.oasis-open.org/xri/XrdOne/SimpleSign#head-99210a926212b687830c5b8a6d3b803844a7783a > 3) If people can use these dsig elements etc., it is likely that they have > XML Dsig liberary > installed. Then, is it not better just to use a standard XML Dsig? Parsing these dsig elements is actually really easy, I don't expect people to pull in a dsig library unless they've got one already. If you don't already use XML DSIG, the right thing to do is parse the XML and interpret the elements yourself. Like I said, the main reason I wrote up the version that reused the XML DSIG elements is because the descriptions from the XML DSIG spec are crisp and clean. If at some point reuse of the spec elements leads to reuse of code, that would be great too. But I won't cry if it never happens.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]