RE: Is an authentication assertion mandatory in SAML?

[Marlena Erdos <marlena@us.ibm.com>]

[Hal wrote:]
By the end of the meeting, my understanding was that Marlena's main
sticking
points were:

1. Shib wants signed artifacts, SAML is not willing to require this
2. The SAML Browser profile which uses artifacts currently proposes that
there be at least one that refers to an AuthN assertion.


Thanks, Hal.  Let me clarify a bit:

    o My primary issue with the type 0001 artifact is
its appropriation of the validity period and audiences
fields in the assertion.   I don't want to mess with
either field in an attribute assertion; I can however
live with "alterations" in an authN assertion.

    o I don't care so much about the authN assertion
requirement per se  as I care about having to
get one *before* I get an attribute assertion.
I know I wasn't clear on this -- I hadn't
reached this conclusion until today.
   If we can have a design that shoves
both at the same time, I'm
okay with that.  We do though need to fully tackle
the subject (no pun intended) of what the Subject
field should be for pseudonymity/anonymity in
the authN and attr assertions. (I've
mentioned this issue but not yet made suggestions.
I know there have been suggestions/debate by others
but I don't recall a concrete proposal.)

    o The Shibb "artifact" I've written about requires
authenticity and integrity.   It doesn't require
signing per se -- I wasn't precise about this at the F2F.
(Does this make it significantly less objectionable?)

    o Lastly, I haven't complained about it (because it
is a secondary issue) but I do not think
that the requirement of a new "partner id"
namespace is a good thing (however necessary it
may be for artifact type 0001). I'll note that the Shibb
artifact doesn't require a new namespace. (Admittedly, one
could argue about which is worse: having to
authenticate the artifact or having to
have a new needs-to-be-configured-and-updated
namespace. (I'm sure it depends on one's environment.))


And, finally, though I have the inclination to
continue to discuss my belief that having
"different artifacts for different environments"
is not at all a bad thing, I'm going to refrain.
Reason: There is a growing movement in Shibboleth
towards using POSTed assertions.  It is far from
a done deal, but it looks promising.  If this pans
out, we would drop the artifact (actually "a handle
package") from our design.   This still leaves
open the question of how impersonation countermeasures
are done.  If we have to POST an authN assertion with
altered validity and audiences fields along with
an attr assertion (with un-appropriated fields),
that is probably livable.  (I still
prefer 'packaging' countermeasure info around the
assertion(s) and leaving those fields alone.)

OK. I'm done.

Thanks,
Marlena