[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> <Subject>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. -will
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]