Phill,
The proposed text is fine for me with just one addition and a nit
(embedded below). I hope the addition is just a clarification and
not going to stir up another hornet's nest:-).
The clarification needed is to say what's meant by "canonical form".
Now, unfortunately rfc2396 doesn't define this explicitly and I don't
know of an explicit definition (not even in the canonical XML
rec [1]!).
Would the following do for now? I'm quite happy that we tweak/tighten
the definition now or later.
By the "canonical form" of a URI we mean an absolute URI (i.e. no
relative URIs) which is the shortest of all the equivalent URI
strings, where URI equivalence is defined according to [RFC2396].
For example, the URI "http://foo.com:80/go/../go/to/" is not in
canonical form, but "http://foo.com/go/to" is in canonical form.
Note that if a URI is partly or entirely case-insensitive, then
there will be more than one "canonical form" for that URI such
that a case sensitive matching rule would consider that the
strings differ (e.g. "HTTP://Foo.cOm/go/to" is "another" canonical
form of the URL above).
Btw: nice one - getting around the coformance muddle by imposing
security conditions - I like that!
Stephen.
[1] http://www.w3.org/TR/xml-c14n
[RFC2396] ftp://ftp.isi.edu/in-notes/rfc2396.txt
"Hallam-Baker, Phillip" wrote:
> [...]
> 2.4.4. Element <AuthorizationDecisionStatement>
>
> The <AuthorizationDecisionStatement> element supplies a statement by the
> issuer that the request for access by the specified subject to the specified
> resource has resulted in the specified decision on the basis of some
> optionally specified evidence.
>
> The resource is identified by means of a URI. In order for the assertion to
> be interpreted correctly and securely the issuer and relying party MUST
> interpret each URI in a consistent manner. Failure to achieve a consistent
> URI interpretation can result in different authorization decisions depending
> on the encoding of the resource URI. To avoid ambiguity resulting from
> variations in URI encoding SAML applications SHOULD employ the URI
> cannonical form wherever possible as follows:
>
> * The assertion issuer SHOULD encode all resource URIs in canonical
> form.
> * Relying parties SHOULD convert resource URIs to cannonical form prior
> to processing.
>
> Inconsistent URI interpretation can also result from differences between the
> URI syntax and the semantics of an underlying file system. Particular care
> is required if URIs are employed to specify an access control policy
> language. The following security conditions should be satisfied by the
> system which employs SAML assertions:
>
> * The URI syntax is case sensitive. If the underlying file system is
s/The URI syntax is/Parts (see [RFC2396]) of the URI syntax are/
> case insenstive a requestor SHOULD NOT be able to gain access to a denied
> resource by changing the case of a part of the resource URI.
>
> * Many file systems support mechanisms such as logical paths and
> symbolic links which allow users to establish logical equivalences between
> file system entries. A requestor SHOULD NOT be able to gain access to a
> denied resource by creating such an equivalence.
>
> The <AuthorizationDecisionStatement> element is of type
> AuthorizationDecisionStatementType, which extends
> SubjectStatementAbstractType with the addition of the following elements (in
> order) and attributes:
>
> Resource [Optional]
> A URI identifying the resource to which access authorization is sought.
>
> [Also fix section 3.3.5 to reference]
>
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
>
> 781 245 6996 x227
--
____________________________________________________________
Stephen Farrell
Baltimore Technologies, tel: (direct line) +353 1 881 6716
39 Parkgate Street, fax: +353 1 881 7000
Dublin 8. mailto:
Ireland http://www.baltimore.com
