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] OpenID Delegating relationship in XRD

> Dirk Balfanz wrote on 2009-09-04:
> >> Keep in mind that we should optimize for the common case. If it's going
> to
> >> be common to put extensions inside Link, it may be simpler to just wrap
> >> KeyInfo in something and solve the ambiguity that way.
> >
> > This does seem weird. Shouldn't the fact that we're using a different
> > name space be enough of a hint that this is an extension?
> Scott Cantor wrote on 2009-09-04:
> If you want the gory details I can provide them, but no, it's not, not
> when
> all your content is optional and you already have a non-wildcard child
> element from another namespace explicitly defined in the schema.
> The other possible fixes are:
> - wrap the other child element into this namespace (KeyInfo in this case)
> - make the other child element a formal extension (not listing it
> explicitly
> in the schema)
> I hadn't proposed the latter before, but it is a possible fix.

Scott, this potentially is a really good fix. The problem with the
Extensions element is that implementers are already used to sticking their
extension elements directly in as children of <Link> (formerly <Service> in
XRDS). Plus just using namespace-qualified extension elements is natural in

So if we can solve the problem by not explicitly listing the
non-XRD-namespace elements we use for sigs (ds:KeyInfo and ds:Signature),
but instead treating them as "formal extensions", I really like that

If we did that, how specifically would you suggest going about documenting
the use of elements from the ds: namespace in the spec. Just referencing
them in the Signature Processing section?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]