Following a group review of some of the doc’s, the
following comments and questions arose on -core. I have some more, but haven’t
had time to write them up. I’ll get them out asap.
- Section 3.7.3.2 Session
Authority Rules (Lines 2506-2509), states that the protocol does not
permit partial success and that "any error during the propagation of
logout requests… MUST result in the failure of the overall logout
process ...". Doesn't this imply that somehow logout messages
that "succeeded" need to be rolled back if the request to a
subsequent SP fails? This will be impractical to implement in many
systems since there is no feasible way to undo the logout’s that
were already processed.
- There was a question about why
the “terminate” option of the Name ID Management Protocol was
combined with the ID management and thus now always requires a response to
be returned. In Liberty-based FederationTerminationNotification, the
message could be delivered via an asynchronous SOAP message with no
expected response. It seems to introduce additional overhead. I
couldn’t recall the justification for it.
- Section 2.2.4 (<Issuer>):
Since it is of type NameIDType, an Issuer can have the various attributes
described in the base type (NameQualifier, SPNameQualifier, and
SPProvidedID – in addition to Format). We don’t describe
anywhere if/when you would use those attributes. In fact, if they do
get used, it probably creates some ambiguity for the definition of a
SourceID used in the artifact resolution profile since it says that it is
created from the SHA-1 hash of the <Issuer>.
- Line 753: states that the <Conditions>
element “MAY contain the following elements…” and the
<Condition> element on line 760 is listed as one of these.
However, technically, the <Condition> element actually can’t
appear since it has a type that is abstract (i.e. ConditionAbstractType).
What can be included are “Elements that are derived from
ConditionAbstractType”. This convention is used throughout the
document for other abstract types. Would it make sense to clarify
each such use? Or perhaps we should just briefly mention the convention in
the Notations section at the front of the document.
- People generally find it a bit
confusing that we have the similar terms “asserting party”,
“authority/SAML authority”, and “responder” as
well as “relying party”, service provider”, and
“requester”. I explained that the terms have slightly
different meanings and the term that is used depends on the context of the
discussion. I think we should do 2 things: a) search the specs for the
terms and make sure we’re using the correct one in each context, and
b) somewhere (notation?) make it clear that there are terms defined in the
glossary that have similar, but subtle differences in meaning and that the
proper term depends on the context of the discussion.
- People also find it confusing
that we frequently refer to “principal”,
“subject”, “user”, and
“identity”. Again, we should double-check their usage
and explain their uses depending on context.
- Nit: why are sections 1.2.1
(String Values) through 1.2.4 (ID and ID Reference Values) subsections of
1.2 (Schema Organization and Namespaces)?
Senior Consulting Engineer
RSA Security Inc.
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:rphilpott@rsasecurity.com
|