RE: [security-services] commets on sstc-saml-core-2.0-draft-06.pdf

[Scott Cantor <cantor.2@osu.edu>]

> Comments below:

Thanks...

> - lots new terms are defined and used:  "session authority, session
> participant, identity provider etc etc)  For the reader it would use
useful
> to define these terms more clearly - and perhaps up front (or at least
refer
> out to the glossary)

Guilty as charged for not following our agreed upon rule to provide
definitions when introducing terms. Don't think we need necessarily say
"look at glossary" though, that should be implied.

> - 3.2.2.2 Unknownprincipal, InvalidNameIDFormat InvalidConfirmingSubject
and
> unsupported binding status codes missing that are defined later in doc.

Yes, will collect when things crystalize a bit.

> - 3.2.2.2 How about some other status codes - including unsupported
> operation (e.g particular request protocol not supported)

This is what metadata is for, one wouldn't assume support for a protocol at
an endpoint (or even know what endpoint to use to begin with). Probably need
something generic to say "huh?" though.

> - line 1368 and 1405 "Rules in Section Response".  what does 
> this mean?  is a word missing?

The OpenOffice file is messed up wrt references due to the Word import. The
link there is to the section on Responses to Queries. We need an editorial
clean up of the internal bookmarks in the document.

> - 3.3.4.1 - perhaps re-title as "processing rules" to be 
> consistent with new sections of other protocols

Yeah. Need to generally revisit some of the older text, and the Subject
discussion will impact that section as well.

> - 3.4 Whilst using the term Replying Party - not using Asserting Party
else
> where in doc.  Hence mixing the IdP/SdP Asserting/Relying 
> definition sets. Do we mean to do this?

I definitely meant to try defining an IdP as a SAML authority that supports
this protocol. The SSO profile being one definite instance. Will look at the
SP vs. Relying Party issue, but I generally like the formalism in this
section.

> - line 1510 responder -> identity provider?

Yes, better.
 
> - line 1525.  to be clear:  "issuer" -> "request issuer"

Yes.

> - lines 1536/1537 - not described how this is determined - 
> e.g Subject in the RequestType?

Yes, it's vague intentionally. Basic idea is to support including a token
that demonstrates, for example, that the subject is visiting the request
issuer (like a bearer assertion). Suspect we will end up replacing Subject
altogether with just a choice of BaseID/NameID/EncryptedID, and leave it
open how the requested subject can be represented. Open question is how much
to say in core, and I think the answer will be not much.

> - lines 1533-1580 - is it allowable to have all of these optional
> elements/attributes absent?

Profile-dependent, but believe generally yes. There are default semantics
suggested throughout when things are omitted. Generally, all this stuff is
optional in ID-FF and you can form a pretty minimal request with everything
implied.

Example of a case where something is profile-required is the
AssertionConsumerServiceURL. ECP and SOAP client profiles (for instance)
need a way for the requester to indicate where errors should be returned by
the presenter if it knows the request won't succeed or refuses. Clients
shouldn't need to go after metadata to know what to do.

> - 3.4.1.  definitions of IDPList IDPEntry RequestChain 
> missing from list of elements/attributes

Intentional, for lack of time, and because most of it is pretty much
complete in ID-FF and not "hard" like some of this is.

> - 5.4.7  what about 1.1 interoperability

Haven't looked at any changes to section 5 yet, but hasn't been much sign
that we'll make any. Effectively there's no interop with 1.1 that means
anything once the namespaces have changed, AFAIC. That section was relevant
because 1.1 was backward incompatible, which needed to be called out.

> - 5.4.8  Given that implementation difficulty of combining signed
assertions
> inside signed response do we want to a) say anything - and perhaps say not
> required b) have a simpler example

Think we need more examples period. As for difficulty, I'd say it's slow,
but not significantly more difficult than signing anything else is. Probably
worth mentioning somewhere about the base64 normalization issues with schema
validation, but probably not in core.

> - 7.1 include a DCE AuthenticationMethod identifier
> 
> - 7.3 include Kerberos NameIdentiofier
> 
> - 7.3 include DCE NAmeIdentifier

Text? Suggest we probably follow the existing convention and leave the names
"packed" into a string rather than use NameQualifier, though I would have
used that for the old ones like Windows domain names myself.

Been too long...didn't DCE have a global CDS name for principals? Maybe that
should be used? ;-)

-- Scott