[wss] ISSUE: Use of "URI" vs "URI reference"

["Philpott, Robert" <rphilpott@rsasecurity.com>]

The attached mail describes a topic discussed in the SSTC regarding the use
of the term "URI" vs "URI Reference" as defined in rfc 2396.  I'm not an
expert on this, but the way I understand it is that, technically, anytime
the WSS spec describes a URI in the definition or use of an element or
attribute, if the value can possibly contain a fragment identifier (e.g.
"#mytoken", then the term should be changed to "URI reference".

For example in draft 6, lines 687-8:
687	/wsse:SecurityTokenReference/Reference/@URI
688	This optional attribute specifies a URI for where to find a security
token.

Here, the definition should say it specifies a "URI reference", not a URI.

Also, in line 686, I recommend changing "This element is used to identify a
URI location for locating a security token" to something like "This element
specifies how to locate a security token".

There are a few other uses of URI in the doc that need to be clarified:
 - Line 694: "value of the URI" -> "value of the URI attribute" (not
reference as it is talking about the attribute, not it's value)
 - Line 694: "present, the URI" -> "present, the URI attribute" (ditto)
 - Lines 694-695: "If this attribute is not present, the URI SHALL be
processed as a normal URI."  First, the last "URI" should be a "URI
Reference".  What does it mean to process the URI "as a normal URI"? Is this
normatively defined by an RFC?
 - Table following Line 801: 3rd column heading should be "Algorithm URI
Reference"
 - 1013 and 1014: Not sure - "URI" -> "URI Reference", however, this perhaps
should really be a QNAME instead of URI/URI Reference since the example on
line 1033 uses URI="cid:image";.
 - Line 1414: "URI link" -> "URI reference"

[nit] There is a typo in line 694: "it SHAL be" -> "it SHALL be"

Rob Philpott 
RSA Security Inc. 
The Most Trusted Name in e-Security 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 
mailto:rphilpott@rsasecurity.com 


> -----Original Message-----
> From: david.orchard@bea [mailto:david.orchard@bea.com]
> Sent: Friday, February 01, 2002 1:54 AM
> To: security-services@lists.oasis-open.org
> Subject: RE: [security-services] URI extensions etc
> 
> I couldn't fully parse the messages below, but I'll try my best at
> helping.
> I'll give a short version then a much too long explanation.
> 
> I like Phil's suggestion of using fragment identifiers, but I suggest a
> tweak that IDREF is used rather than anyURI.  I also support using
> relative
> URIs and xml:base.  These are different issues, believe it or not.
> 
> <long>
> 1. URI references do not need a "#" as defined by rfc 2396.  URI reference
> may be absolute, relative or contain a fragment identifier.  xml:base
> defines how relative URIs are used to generate absolute URIs and says
> nothing about fragment identifiers.  Please note the following statement
> in
> section 4 on URI references from rfc 2396,
> 
> [However, "the URI" that results from such a reference includes only the
> absolute URI after the fragment identifier (if any) is removed and after
> any
> relative URI is resolved to its absolute form.]
> 
> xml:base does not over-ride rfc2396, so I'm not sure what it does.  I've
> asked the editor.  I'm not sure fragment identifiers should be used with
> relative references.
> 
> Now it is common to use fragment identifiers BUT they are typically either
> "bare" or absolute and never with a relative URI.
> 
> 2. I don't think that xml:base has to be defined in SAML schema to be
> supported.  SOAP 1.2 supports xml:base but does not include it in the SOAP
> 1.2 envelope schema.  Sadly, I will even ref the soap envelope namespace
> name - http://www.w3.org/2001/12/soap-envelope.  It would be strange if
> SAML
> could be expressed in SOAP 1.2 but did not support xml:base.   It would be
> a
> simple matter to define how SAML would use xml:base in a SOAP 1.1 message.
> 
> 3. FWIW, xml:base also defines an algorithm for creating a base infoset
> property from the protocol.  SOAP 1.2 faithfully does this.  SAML would
> automatically get the base infoset item from a SOAP 1.2 processor and it
> would be set according to the resolving relative URI references algorithm.
> 
> You could use either relative URIs or absolute with fragment identifiers
> or
> fragment identifers.  But not relative URIs with fragment identifiers.
> 
> I strongly support use of xml:base for relative URI resolution - in fact I
> was a champion of them for soap 1.2 along with Chris Ferris of Sun.  Here
> is
> a sample for SAML:
> [All URIs used in SAML MAY be either absolute or relative.  SAML does not
> define a base URI but relies on the mechanisms defined in XML Base and RFC
> 2396 for establishing a base URI that may be used when absolutizing URIs.
> SOAP 1.1 does not explicitly support XML Base and the base URI might not
> be
> set by a SOAP 1.1 processor.  A SAML processor MAY be required to
> determine
> the base URI as defined by XML Base, such as examining the xml:base
> attribute in the SOAP 1.1 envelope.
> SOAP 1.2 supports XML Base.  A SAML processer MUST use the base URI as set
> by a SOAP 1.2 processor
> ]
> Another place to put wording on XML Base is in the protocol binding, as
> the
> base uri set by the protocol is part of the xml base and rfc 2396
> algorithm.
> 
> 
> But this is orthogonal to the use of fragment identifiers as I think Phil
> brought them up.  Phil brought up the use of fragment identifiers which is
> not covered by the xml:base spec - xml:base talks about relative URIs
> which
> EXCLUDES fragment identifiers.   If you use the anyURI data type, you must
> use the fragment identifier syntax, ie #id.  Or you must use an absolute
> URI
> with a fragment identifer, ie http://foo.com/bar#id.    There is NO xml or
> XML Schema data type for URIs with only fragment identifiers or absolute
> URIs.  Let us not go into the issue of defining URI data types.  So if you
> use the anyURI type, then you have to decide what to do about allowing
> relative URIs and fragments.  And you can only do it in spec land, not a
> schema definition.  And there the merry-go-round begins.
> 
> Another option would be to use the IDREF type rather than anyURI type.
> This
> has the nice feature that most XML parsers will do ID/IDREF checking.  And
> lo, SOAP 1.2 had extensive discussions on using IDREF rather than anyURI
> for
> SOAP encoding references (exactly what I think is being proposed here),
> led
> by Marc Hadley of Sun.
> http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0131.html.  Most
> members of XMLP found the IDREF arguments pretty convincing fwiw, though I
> can't say publicly what the xmlp resolution was.  W3C members can find the
> XMLP resolution.
> 
> I think it's safe to say that relative URIs and IDREFs are acceptable
> industry practice.
> </long>
> 
> My $.02 Canadian worth,
> Dave
> 
> > -----Original Message-----
> > From: Eve L. Maler [mailto:eve.maler@sun.com]
> > Sent: Thursday, January 31, 2002 5:56 PM
> > To: security-services@lists.oasis-open.org
> > Subject: Re: [security-services] URI extensions etc
> >
> >
> > I must have missed this discussion; what was the benefit
> > claimed for this
> > approach?  (I'm not necessarily against it.)
> >
> > This approach points up the importance of talking about URI
> > *references* in
> > the text, not just URIs.  I think I've commented on this
> > before.  ("URI
> > reference" means the URIs that are allowed to have have fragment
> > identifiers on them.)  If we don't say we allow URI references, then
> > fragment identifiers technically aren't allowed, though I
> > doubt there's
> > much software that would hold implementations to this restriction.
> >
> > (I'm not too crazy about messing with base URIs; their
> > semantics are a
> > little tricky.  BTW, xml:base is one of those pseudo-native
> > XML attributes
> > that can't be validly used unless we really include it in our
> > schema...  I'd rather have whole URI references be spelled out.)
> >
> >          Eve
> >
> > At 05:46 PM 1/31/02 -0800, Hallam-Baker, Phillip wrote:
> > >One issue that was raised was the issue of expressing
> > identifiers as URI
> > >fragments.
> > >
> > >I.E. if our base spec is http://foo.bar/base then the
> > identifiers defined
> > >therein should
> > >be of the form http://foo.bar/base#X #Y #Z etc rather than the
> > >http://foo.bar/base/PKCS7
> > >style I used.
> > >
> > >This would also change RespondWith slightly so that the
> > identifiers were all
> > >nominaly
> > >fragments off the default URI which would be the base URI
> > for the spec.
> > >
> > >All this means in practice is we introduce some # characters
> > in several
> > >spots.
> >
> > --
> > Eve Maler                                    +1 781 442 3190
> > Sun Microsystems XML Technology Center   eve.maler @ sun.com
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>