[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] ISSUE: Fragment identifiers for URI references on the Format attribute
Eve, looking through our code, I find that all we do is treat the fragment identifiers as strings: #emailAddress etc. Is this bad? I guess the problem is that they may also validly be complete URLs. - prateek >>-----Original Message----- >>From: Eve L. Maler [mailto:eve.maler@sun.com] >>Sent: Tuesday, June 25, 2002 11:55 AM >>To: Eve L. Maler >>Cc: 'security-services@lists.oasis-open.org' >>Subject: Re: [security-services] ISSUE: Fragment identifiers for URI >>references on the Format attribute >> >> >>I have finally had a chance to consult with Paul Grosso, chair of the >>W3C XML Core WG and an expert on the subtleties of base URIs. >> I believe >>that we do need to make a change, and that we need to discuss >>this topic >>in today's call. >> >>By the way, I never did hear back from any developers on what their >>Format values are looking like. Can people weigh in on this? >> >>Briefly: >> >>- URNs can have fragment identifiers, so it's not strictly >>wrong for us >>to give fragment IDs to them. However, no one ever really >>uses them, so >>implementation experience is sparse. >> >>- I was wrong about application-dependent base URIs being a solution. >>They are the last in a chain of base URI building, and >>typically they're >>never reached because something else (e.g., the location of a file) >>takes precedence. >> >>- In any case, if anyone does use just a fragment ID and not >>a whole URI >>reference for the Format attribute, the correct >>interpretation is *not* >>to add a "base URI" coming from some unknown source; empty >>URI portions >>always refer to the *current document* and never to a base. >>(Base URIs >>are *incomplete* URIs that must be completed by the addition of a >>relative URI.) >> >>- In talking about URI-based identifiers, we gloss over some >>important >>distinctions. Because we don't restrict these to *absolute* URI >>references (as the XML Namespaces spec does), we're caught >>not knowing >>how to apply different stages of normalization and >>absolutization that >>URIs usually go through. >> >>- If we were to insist that URI-based identifiers always be >>absolute, we >>solve most potential interoperability problems. >> >>- If we later get rid of our own fragment IDs for Format >>attributes, we >>take away some confusion. >> >>My recommendations: >> >>1. That we add, somewhere in a cs-sstc-core-02 if possible, the >>statement that URI-based identifiers are REQUIRED to be >>absolute in form. >> >>2. That if the next version of SAML is an increment to the >>minor version >>number, we add an alternate set of URNs corresponding to the >>Format choices. >> >>3. That in the next version of SAML that increments the major version >>number, we replace the old fragment ID-based Format values with the >>URN-based values. >> >>I'm not sure of our leeway to make changes such as #1 above >>at this late >>date, but if we don't make this change, there's definitely an erratum >>lurking in our future on this. >> >> Eve >> >>Eve L. Maler wrote: >>> The following is a relatively minor set of potential issues >>on SAML 1.0 >>> Committee Spec-01. Note that we're going to need a process for >>> collecting issues going forward, or at least we need to >>continue our >>> existing process... >>> >>> * * * >>> >>> In cs-sstc-core-01, lines 599-615 contain the only use of fragment >>> identifiers in the whole spec anymore: they describe the >>values for the >>> Format attribute, such as #emailAddress, on <NameIdentifier> . I'm >>> wondering why we didn't make these whole URNs, as we >>ultimately did for >>> everything else. Also, here we refer a bit obliquely to base URIs: >>> "assuming a base URI of the SAML assertion namespace name" >>(lines 600-601). >>> >>> I have the following concerns: >>> >>> - Did we mean that it should be possible to set an explicit >>base URI >>> somewhere and then in the Format attribute use only the >>fragment ID? If >>> so, were we assuming that the base URI would be set using >>the XML Base >>> spec? If we were relying on XML Base, we would have to >>make explicit >>> reference to it in the text; you don't get XML Base free by >>using XML >>> (yet). >>> >>> - Alternatively, did we mean that SAML has its own >>application-specific >>> semantics about the base URI? This may be perfectly acceptable >>> ("application-dependent semantics" as defined in RFC 2396); >>I just think >>> our text isn't quite clear enough in this case. >>> >>> - The semantics for base URIs are really tricky; I'm not an >>expert, but >>> I'm concerned we may be breaking the semantics for "empty" >>URIs (such as >>> the empty URI string a Format attribute value of >>"#emailAddress") if we >>> do assume that the base URI is set elsewhere and can be >>implicit on the >>> Format attribute. >>> >>> The good news, if there are issues here, is that the >>workaround is to >>> always supply the whole URN+fragID. (What is current practice by >>> implementors?) >>> >>> Assuming that my fears about "empty" URIs are unfounded (I >>will check >>> with a base-URI expert of my acquaintance), an easy >>fix/enhancement in >>> the direction of application-specific base URIs would be to >>clarify the >>> "assuming a base URI of the SAML assertion namespace name" >>wording. This >>> is perhaps a minor enough clarification that there may be a >>way to do it >>> for the OASIS Standard level, if we get that far... >>> >>> If we want to allow the use of XML Base (that is, the xml:base >>> attribute), the change would be quite a bit more invasive. >>We'd want to >>> explicitly allow for the attribute in our schemas, and make >>normative >>> reference to the XML Base spec from our core spec. I >>wouldn't want to >>> go here for a while. >>> >>> Eve >> >> >>-- >>Eve Maler +1 781 442 3190 >>Sun Microsystems cell +1 781 883 5917 >>XML Web Services / Industry Initiatives eve.maler @ sun.com >> >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC