OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] comments on SAMLCore CD 01


Hi John,

I was charged with providing a formal response that documents which of your
suggestions have been incorporated, and which haven't (with some
explanation). Where fixes are mentioned, these are in the post-CD drafts
(CD-1b is the latest).

> Line 330 - "An assertion is a package of information that 
> supplies one or more statements." Both the schema and other 
> places in the text (like line 536) give the cardinality as 
> zero or more.

Fixed.

> Line 611 - Here and throughout the document, the <BaseID> 
> element is used as if it could appear in some XML document 
> context. However, it is an abstract type; perhaps it should 
> be replaced with "A concrete type derived from <BaseID>".

<BaseID> is an element, not a type. Types cannot appear in instances, so it
is correct usage to say that <BaseID> can and will appear in an instance. It
just has to have an xsi:type with it. There are numerous cases of this in
the spec (<Statement>, <Condition>).

> Line 1134 - Insert "non-schema simple" between "Specifying a 
> " and "datatype on <AttributeValue>". An extension schema 
> would not be needed for a built-in XML Schema type.

Fixed.

> Line 1389 - If the signature is valid, why would the 
> responder "MAY process the request or respond with an error"? 
> See for comparison lines 1453-1455.

I added some clarification to this. Signature validation is merely one of
many things a responder has to do to determine the validity of a request.

> Line 1477 - Is <StatusDetail> only for error conditions? That 
> is the interpretation here and at lines 1571-1572. However, 
> lines 1497-1498 indicate that it can be used when the status 
> is "success".

Fixed.

> Line 1984 - What is the point of the empty sequence 
> (<sequence />)? It appears that the element doesn't have any 
> sub-elements (line 1955); this is also the case for line 2050.

Fixed.

> Lines 2082-2083 - Please specify whether a set of assertions 
> returned as the result of an <AuthnReqest> must supply a 
> <AuthnStatement> in just one assertion, or in every assertion 
> in the set.

This is clarified.

> Line 2256 - s/RegisterNameIDRequestType/ManageNameIDRequestType
> 
> Line 2521 s/NameIDRequestType/NameIDResponseType              
>      s/RequestAbstractType/StatusResponseType

Fixed.

> Line 3037 - No support for HTTP DELETE? Sections 8.1.1 and 
> 8.1.2 both have the notion of a delete operation.

I think in the spirit of freezing the Authz functionality in favor of XACML,
this has been left alone, since we'd have to add a new 2.0 identifier for
this. I would have liked to see the language a bit stronger telling people
that they should be very cautious about using the Authz pieces if they
aren't already.

> In general - There is little guidance with regards to XML 
> Encryption. It would help to offer some guidelines in areas 
> like recommended algorithms (as is done with SSL/TLS), 
> encryption by different parties, super-encryption, etc. Some 
> (non-normative) examples would be especially useful.

The SSL stuff is gone, and has been moved to conformance where it belongs,
and there are some Encryption-related algorithm requirements there now. The
other issues don't appear (to us) to require any profiling. Examples will
show up eventually, but are non-normative and since I don't have working
code to produce them, I haven't done it.

Thanks,
-- Scott



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]