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: subject sets (also sort of: Agenda for August 6, 2009 call)

John Bradley, Nat Sakimura, and myself were present on the call.  So  
perhaps this will be a lesson in what happens when folks don't show up  
on the call :)

We spent a fair amount time going back over a few of the trust  
methods, subject matching, etc, then arrived upon subject sets.  We  
revisited some of the earlier discussion about using non-information  
resource identifiers for a host-wide XRD.  So let me back up and  
follow the same train of thought that had...

## Subject Matching Rules ##

We have at least three potential use cases for matching the value of  
an XRD Subject to something:

First, in the PKI trust model, a consuming applications trusts the  
signature of an XRD if:
  - the signature is valid for the document (of course)
  - the certificate was issued by a trusted certificate authority
  - the subject of the certificate matches the authority of the XRD  
Subject URI

Second, when linking from one XRD to another (using the XRD "seeAlso"  
rel value), the XRD/Link/Subject of the first XRD must match the XRD/ 
Subject of the second XRD.  Previously we had talked about having an  
implicit value, which was the XRD/Subject of the first XRD (basically,  
the two Subjects had to match), but the current draft of the spec  
requires that the <Link> explicitly define a Subject value, even if it  
is the same as the XRD Subject.

The third potential use case for Subject matching was a little less  
clear.  This has to do with the first XRD discovered for a given  
resource.  Is the XRD Subject matched against the resource URI which  
was used to discover the XRD document?  I don't believe the language  
is in the spec any more, but there use to be specific mention  
somewhere that it was *not* required to match.  This is because the  
XRD Subject is the canonical URI for the resource, whereas the  
consuming application may have used a non-canonical URI to discover  
the XRD.  This is why we have the Alias element, which lists other non- 
canonical URIs for the resource.  So my question is this:  Is it a  
requirement of XRD Trust that the resource URI used to discover the  
XRD document be present in the document itself, either as the Subject  
or as an Alias?

I know that it is (or should be) a requirement that the XRD Subject  
have the same authority as the resource URI used to discover the XRD,  
since anytime you pass between authorities you need some kind of  
Signature (this was the whole argument for using XRD for host-meta in  
the first place).

None of the three of us on the call could remember whether it was  
required that the resource URI used to discover the XRD be referenced  
in the XRD itself.  John was under the impression that this is not  
required.  I honestly couldn't remember.  So that's something we  
definitely need to establish.  Is that something we had intended all  
along?  Does it make sense to require this?  What's the risk if it's  
not part of XRD Trust?

The rest of the call was spent talking about the ramifications of this  
*not* being a requirement of XRD Trust.  If we decide that it *is*  
really necessary, then nothing in the rest of this email would be valid.

## No need for explicit Subject sets ##

So we're working under the assumption that the XRD Subject is not used  
in the third use-case mentioned above, since that check is not  
actually performed.  We can also safely say that this XRD Subject is  
not being used in the second use-case mentioned above, because any  
linked XRDs must have an explicit XRD/Link/Subject.  That means that  
this particular XRD subject is only actually used for validating the  
certificate used to sign the XRD.  If that's the case, then it doesn't  
really matter too much what the Subject URI value is, so long as it  
has the correct authority.  At this point, either John or Nat brought  
up non-information resources.  I know Drummond actually brought this  
up before, but it was never really explored very much and it actually  
makes a lot of sense here.  A Subject value of "http://example.com/#";  
would satisfy the need for matching the certificate subject, without  
requiring any new schema.

## XRD Subject is the canonical identifier for the resource ##

In the process of writing this email, one other thing occurred to me,  
which will actually need to be addressed whatever we do about subject  
sets.  When a Subject element appears as a direct child of XRD, it is  
defined as identifying the canonical URI for the resource described by  
the XRD.  Take either of the following Subject values for a multi- 
subject XRD:

   <Subject match="beginswith">http://example.com/</Subject>

If the resource URI I used to discover the XRD document is "http://example.com/foo 
", then what is the actual canonical identifier for the resource?  I  
would argue that its the resource URI itself "http://example.com/ 
foo".  That would mean that our definition for what Subject means is  
true only when talking about a single-subject XRD.  When talking about  
a multi-subject XRD, then the Subject element identifies either:

   - in the first case, it identifies a URI that can be matched  
against the resource URI.  But really, what's the value of matching it?
   - in the second case, it identifies an abstract non-information  
resource which very likely means nothing.

In neither case does the Subject actually identify the canonical  
identifier for the resource.  In both cases, the canonical identifier  
for the resource can only be the resource URI that was initially used  
to discover the XRD document.  Is this the desired semantic?

I'm beginning to give myself a bit of headache thinking about all  
this, so I'll leave it at that.  Believe me, I'm the last person who  
would want to drag out this discussion and further delay an XRD  
committee draft.  But I can't shake the feeling that this subject  
matching stuff feels really weird, and perhaps unnecessary.


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