A question of conformance

[Will Norris <will@willnorris.com>]

A couple of follow up questions from last weeks call regarding conformance...

## Conforming XRD Documents

First, we talked about adding a new conformance section for XRD Documents, basically saying that they must validate against the XRD schema.  Then, we were going to say something along the lines of "XRD consumers MUST implement parsing of conforming XRD documents, as defined in Section 7.x".  Additionally, we were going to make it optional got consumers to support the <XRDS> element, since we figure most implementations will ignore it anyway.  So here's where it gets interesting...

According to the XRD schema, any XRD element can appear as the root element of a document.  Additionally, an XRD element can appear inside of some other non-XRD document.  Scott pointed this out very plainly when we were discussing the schema, and everyone seemed to be okay with that.  So all of the following are conforming XRD documents, insomuch as they validate against the XRD schema:

<?xml version="1.0"?>
<Link xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0"; />

<?xml version="1.0"?>
<foo xmlns="http://example.com/"; xmlns:xrd="http://docs.oasis-open.org/ns/xri/xrd-1.0";>
    <xrd:XRD />
</foo>

<?xml version="1.0"?>
<XRDS xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0"; ref="http://example.com/"; />

(Well, I'm not actually sure about the second one.  It doesn't violate the XRD schema, but may require an additional schema for the "http://example.com/"; namespace to fully validate)

Are we comfortable saying that these are all conforming "XRD Documents"?  Or rather does the definition of an "XRD Document" need to be constrained to documents which have a root element of <XRD> (and maybe <XRDS>)?  If we don't constrain the definition, then this has interesting implications for the conformance requirements of XRD consumers.


## Signature Algorithm

On the call, Scott mentioned that support for RSA-256 should be required of both XRD providers and consumers (or at least those that support XRD Signatures).  I understand what it means for consumers to be required to support this, but I'm not sure what it really means for providers.  We would not be saying that all XRD documents MUST use RSA-256, rather we're providing a reasonable baseline that implementation can be assured will be supported.  But what good is requiring RSA-256 support from providers if they can simply always publish using something else?  It's not like the signing algorithm is being negotiated in real time between the two parties (like OpenID associations).

I think it's reasonable to just require RSA-256 support of consumers.  XRD providers can then infer from that requirement that if they calculate signatures using RSA-256, all conforming consumers will be able to verify it.

(as an aside and for those that followed the discussion on openid-specs, this is also my concern for "requiring" support for certain attributes in the next OpenID AX spec.  It's meaningless for providers if they can simply always choose to do something else)