[OpenID] host-meta and "acct:"

[Santosh Rajan]

Why are you guys so stuck up on allowing XRD's with no Subject?

If you really want to do that, why don't you allow for an "Anonymous XRD"
who's Subject is empty?

That is what the RDF folk did (its equivalent). Are you suggesting that you
guys know something which those guys didn't know? (I had to reread the RDF
spec to confirm this).

If that is the case why don't you clearly explain to everybody why the XRD
need not have a Subject Element?


On Wed, Nov 4, 2009 at 1:54 PM, Will Norris <will at willnorris.com> wrote:

>
> On Nov 1, 2009, at 8:13 AM, Peter Williams wrote:
>
>  Yes. Only the XRD element has an xml:id attribute, schematically. But I
>> could not detect your point, of saying this fact.
>>
>
> I imagine he was responding to your statement that:
>
>
>  The subject has to bear the xml:id
>>
>
> XRD's extensibility model certainly allows you to put an xml:id on the
> <Subject> if you want to, though that would certainly not be the xml:id used
> as the <ds:Reference> in the signature.  The Signature, if present, MUST
> reference the xml:id attribute of the root XRD element being signed.  Keep
> in mind that this may or may not be the root element of the XML document, as
> in the case of XRDS.
>
>
>
>  And, a subject name is about an XRD in a context (in general). One such
>> context is the native signing/trust model (if used).
>>
>
> I'm not completely sure what you mean here.  The subject identifies the
> resource the XRD is about, regardless of "context" (maybe depending on how
> you define context?).
>
> To maybe clear up some of the discussion around Subject, and whether or not
> it is required (and hopefully not to re-open a can of worms that has seemed
> to die down)...  (and I realize I just sent some of this in another thread
> on this list, but it's worth repeating)
>
>
> An XRD Subject is effectively useful for two things.
>
>  1. It identifies the resource the XRD is about
>
>  2. It is anticipated that some XRD trust profiles will use the subject URI
> to varying degrees to assess the trustworthiness of a signed XRD.  One
> example is by comparing the subject URI to key material used to generate the
> signature.  None of these XRD trust profiles have been written yet, so no
> one can say with any certainty exactly what they will contain.  I CAN tell
> you that we have discussed profiles that will most certainly make use of
> Subject, and we have also discussed profiles that will very likely NOT make
> use of Subject.
>
>
> Subject is not a required element of XRD.  What it actually means for an
> XRD to lack a Subject depends on a few things...
>
>  2. If the XRD is signed, then clearly it must be using a trust profile
> that does not require a Subject.  Remember, no XRD trust profiles exist yet,
> but we do anticipate that there will be one or more that won't require a
> Subject.  That can't be said with any certainty because we just don't know
> yet.
>
>  1. How do you know what resource an XRD is about if you don't have a
> subject?  As far as XRD proper is concerned, the answer is undefined.  XRD
> 1.0 gives you one way to identify the resource the XRD is about, but says
> nothing about what it means if the Subject is absent.  This is
> intentional... we didn't want to preclude other ways of identifying the
> subject (or maybe even subjects, plural) of the XRD.  What implication will
> these other subject-identifcation methods have on applications and protocols
> that use XRD for resource description?  We can't really answer that, because
> we don't know.  For the use-cases we've been able to identify so far, and
> the ones we've had in mind while designing XRD, it seems to work out okay.
>
> It is entirely possible that some applications will require the presence of
> an XRD Subject element, and that's perfectly okay.  XRD can be profiled to
> add whatever additional constraints a particular application or protocol
> needs to be useful, secure, scalable, etc.
>
> So what about XRDs that don't contain a Subject element, nor contain any
> other defined way of identifying the resource(s) the XRD is about?  Again,
> this is undefined.  If you're unable to identify (by whatever means) the
> subject (explicit or implied) of the XRD, I can't tell you what that means.
>  It doesn't sound terribly useful.  Would it be a valid XRD?  Yes,
> absolutely.  Is it a useful XRD?  No, probably not, though someone may come
> up with a valid case for it.  By the same token, the following is also a
> completely valid XRD document:
>
> <XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0" />
>
> It's not useful at all, but it's entirely valid.
>
>
> Try not to get too hung up on Subject.  In many common use cases, Subject
> will be present, and you won't have to worry about it.  In cases where
> Subject is not present, then there will need to be some other defined means
> for providing the necessary information to address common uses that Subject
> is used for.  As long as you have some other means to identify the resource
> the XRD is about and, if necessary, a way to assess the trustworthiness of a
> signed XRD, then you can get by just fine without a formal Subject element.
>
> -will
>
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>



-- 
http://hi.im/santosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20091104/7eb6d466/attachment.htm>