This discussion on PE5 is timely as I had just begun to throw together some material on identity federation, how it is achieved etc., for the technical overview.
One concern I have with both the proposed resolution is the claim that working with persistent identifiers (8.3.8)
"implicitly results in a new identifier being created during
the handling of most requests"
There are many use-cases where this is statement is false. In one actual deployment, the IdP pushes lists of persistent identifiers to SPs over a reliable back-channel in a batch mode.
The creation of an identifier as a consequence of SAML 2.0 requests is actually a special and somewhat complicated case quite separable from the use of "persistent" as an ID format; I would be concerned about adding text to core that suggests otherwise.
- prateek
PE5: Rules for NameIDPolicy
Probably needs more discussion in light of Brian's recent posting of other
concerns about AllowCreate to saml-dev, but the erratum is specifically
addressing transient.
I see two options, the strict reading and the "common sense" reading. Either
involves adding text after line 2147 of [SAMLCore].
Strict:
"Finally, note that since the
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent Format value (see
Section 8.3.8) implicitly results in a new identifier being created during
the handling of most requests, the AllowCreate attribute MUST be set to true
in order for such a value to be returned."
Optimized:
"Finally, note that since the
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent Format value (see
Section 8.3.8) implicitly results in a new identifier being created during
the handling of most requests, the AllowCreate attribute MUST be ignored by
the identity provider
when such an identifier is requested or issued."
I favor the latter. I also agree with Brian that we need more guidance on
what the point of AllowCreate really is. I think it's hard to separate it
from the issue of "consent", personally, and might have been better handled
with processing rules based on the Consent attribute, but that's water under
the bridge.
I do think the practical meaning of AllowCreate is potentially format
specific, so it might be best just to acknowledge that.
---
PE6: Encrypted NameID
[SAMLCore]
Append to paragraph ending on line 2139:
"It is not possible for the service provider to specifically request that a
particular kind of identifier be returned if it asks for encryption. The
metadata element (see [SAMLMeta]) or other out-of-band
means MAY be used to determine what kind of identifier to encrypt and
return."
---
PE7: Metadata attributes
WantAuthnRequestsSigned and AuthnRequestsSigned
PE9: Clarification on SP AuthnRequestsSigned and the IdP
WantAuthnRequestsSigned SP metadata flags
I'll lump these together (Jahan, maybe combine them into a general "clarify
metadata "signing" flags" or something like that). I'll take a lightweight
approach to this by proposing text in the metadata spec rather than
attacking the profile text with a lot of precise rules.
[SAMLMetadata]
Add text before line 710:
"The WantAuthnRequestsSigned attribute is intended to indicate to service
providers whether ot not they can expect an unsigned message
to be accepted by the identity provider. The identity provider is not
obligated to reject unsigned requests nor is a service provider obligated to
sign its requests, although it might reasonably expect an unsigned request
will be rejected. In some cases, a service provider may not even know which
identity provider will
ultimately receive and respond to its requests, so
the use of this attribute in such a case cannot be strictly defined.
Furthermore, note that the specific method of signing that would be expected
is binding-dependent. The HTTP Redirect binding (see [SAMLBind] sec XX)
requires the signature be applied to the URL-encoded value rather than
placed within the XML message, while other bindings generally permit the
signature to be within the message in the usual fashion."
Add text to paragraph at lines 741-742:
"A value of false (or omission of this attribute) does not imply that the
service provider will never sign its requests or that a signed request
should be considered an error. However, an identity provider that receives
an unsigned message from a service provider whose
metadata contains this attribute with a value of true MUST return a SAML
error response and MUST not fulfill the request."
Add text to
paragraph at lines 744-747:
"Note that an enclosing signature at the SAML binding or protocol layer does
not suffice to meet this requirement, for example signing a
containing the assertion(s) or a TLS connection."
---
I guess others have actions to address some of the other issues.
-- Scott
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php