OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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]