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] Additional comments on core-02


On a couple of the points below:

Scott Cantor wrote:
...
>>4.	Lines 682-689: The use of the phrase "while confirming 
>>itself" is pretty confusing and could really use some 
>>additional explanatory text.  Does this mean the attributes 
>>are only used when the entity presenting the assertion is the 
>>"subject" of the assertion?
> 
> 
> No, it means they're used when evaluating subject confirmation. Core doesn't
> define when that is precisely. At least it never did before. I reworded a
> little bit to clarify that the attributes apply to the characteristics of an
> action performed by a "confirming entity", not the subject. We should make
> sure that term is in the glossary.
...

I sent mail to Jeff asking that he add "confirming entity" to the 
glossary, which currently doesn't have it.

...
>>6.	Lines 978-979 re: the note that AuthorityBinding was 
>>removed.  Should we clutter up the core spec with these 
>>notes?  I think they should just go in the 1.1/2.0 
>>differences section of the tech overview. If we want to 
>>include them, we should go through the spec to mention them 
>>all.  For example, we don't mention that the 
>>AttributeNamespace attribute was removed in section 2.7.3.1. 
>>Lines 1383-1384 do describe removal of <RespondWith>.
> 
> 
> Well, we mentioned all the things we removed that have no new equivalent.
> Eg. AttributeNamespace was replaced with NameFormat and more liberal
> wildcarding.

We put in notes for these because we advertised in V1.1 that they were 
going to come out in V2.0 in backwards-incompatible fashion.  I can see 
an argument for removing the notes since we also did a lot of other 
invasive stuff between then and now.

>>7.	Line 1046: While I know what the "or both" clause is 
>>referring to once you read the schema, it's not a very clear 
>>description.
> 
> 
> But it's precise. And the schema is part of the spec. You aren't expected to
> be able to read the spec without it. I think we've been less than firm on
> that point. Syntactically, the schema is the spec.

Slightly OT, but it was recently pointed out to me that our text 
explaining the precedence of schemas/prose is somewhat out of whack. 
What we had wanted to say is that the schema listings in the specs are 
illustrative only (the machine-readable real .xsd files hold sway if 
there's any discrepancy), but that the prose often contains extra 
constraints beyond the schema grammar and is therefore authoritative. 
We hadn't wanted to use wording saying the (non-schema-snippet) prose 
literally "takes precedence", but in fact that's the only practical 
solution when we have these added constraints.  What we've got is 
therefore confusing.

S'okay with folks if I change from this:

"This specification uses schema documents conforming to W3C XML Schema 
[Schema1] and normative text to describe the syntax and semantics of 
XML-encoded SAML assertions and protocol messages. In cases of 
disagreement between the SAML schema documents and schema listings in 
this specification, the schema documents take precedence. Note that in 
some cases the normative text of this specification imposes constraints 
beyond those indicated by the schema documents."

to this?

"This specification uses schema documents conforming to W3C XML Schema 
[Schema1] as well as normative text to describe the syntax and semantics 
of XML-encoded SAML assertions and protocol messages. The schema 
listings in this specification are illustrative only, and in cases of 
disagreement between them and the machine-readable SAML schema 
documents, the schema documents take precedence.  However, the normative 
text in this specification provides the authoritative interpretation of 
all SAML semantics and processing.  (In some cases, the text 
deliberately defines constraints that go beyond those expressed in the 
schema documents.)"

I believe this appears in all the specs containing schema snippets, so 
it would have to be changed throughout.

	Eve
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com


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