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

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

Hi Chris,

To me, this is not really a major issue - it's simply a matter of technical
accuracy in the use of the terms.  As I said, I'm not an expert on this
specific issue, so I am relying on the info in Eve Maler & David Orchard's
exchange and recollection of the discussion on some SAML con-call meetings.
As it was explained by Eve...

> > 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.

So while the schema definition for URI allows a document fragment, the
descriptions used to talk about absolute URI's, relative URI's, fragments,
etc. in the rfc and other specs are intended to provide consistency and
additional clarity ... thus we used these in SAML.  And so the suggestion is
to use these same definitions within the descriptions of the WSS spec.

As for line 686, my comment didn't provide sufficient context (it was
late... what can I say).  What I meant was that the
"/wsse:SecurityTokenReference/Reference" element is the element that
contains information used to locate a security token.  It is the URI
attribute OF THIS ELEMENT that identifies one of the specific ways to locate
the token.  The extensibility mechanism .../Reference/{any} provides a way
to define other ways to locate it.  So the comment was to generalize the
description of the higher-level /Reference element.

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: Chris Kaler [mailto:ckaler@microsoft.com]
> Sent: Thursday, December 12, 2002 12:30 AM
> To: Philpott, Robert; wss@lists.oasis-open.org
> Subject: RE: [wss] ISSUE: Use of "URI" vs "URI reference"
> 
> This is confusing... "#abc" is a valid "URI" as defined by the XSD
> Schema type.
> 
> RE: line 686, I'm not sure that "how to locate" is best wording as it
> doesn't really specify how, just where.  Does that make sense?
> 
> -----Original Message-----
> From: Philpott, Robert [mailto:rphilpott@rsasecurity.com]
> Sent: Wednesday, December 11, 2002 8:47 PM
> To: 'wss@lists.oasis-open.org'
> 
> 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>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>