Subject/SubjectConfirmation proposal

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

One of the things that's clear to me from trying to work on this
AuthnRequest stuff as well as the side discussion about Subject is that we
ought to come up with a different schema for this stuff. I think the
original schema was developed in the absence of enough use cases to design
it, and it's broken.

(Not that I'm saying I think we necessarily have all the use cases now
either, but there are at least some new thoughts floating around, and some
of them are even almost understandable.)

There are a lot of possibilities, some more radically different than others,
and probably the question of compatibility at a basic level as to be
considered. There are at least some communities establishing practice with
the existing Subject and SubjectConfirmation design, so completely altering
it would have to be done with that in mind.

Also I think almost none of this really impacts the browser use cases or the
bindings. The intermediary, Kerberos, and SOAP client work items are really
the areas this becomes a problem.

I have a possible approach to suggest for discussion:

First, I suggest some slight alterations to my proposed changes to
NameIdentifier and the names in that element hierarchy. Specifically, I
suggest we relax the specificity a bit and do the following:

Rename BaseNameIdentifier/Type to BaseIdentifier/Type
Rename EncryptedNameIdentifier/Type to EncryptedIdentifierType
--- makes it more reasonable to "identity" a subject using some kind of
complex structure or token, such as a Kerberos ticket. This is an
identifier, perhaps, but isn't really a name.

Second, I suggest we adopt the semi-proposed motion to factor out Subject
and eliminate multi-subject assertions. Subject would be optional, I
suppose.

Third, I suggest we change SubjectConfirmation as I suggested once or twice
in separate notes, to better align the ConfirmationData/KeyInfo with the
corresponding ConfirmationMethod. There would just be repeating
SubjectConfirmation elements, but each one just gets one method. I don't see
how to interpret what's there now.

Fourth, Ron suggests providing a way to identify a confirming entity inside
a SubjectConfirmation element. To do that, I would simply add an embedded
choice of BaseIdentifier/NameIdentifier/EncryptedIdentifier.

Fifth, and perhaps optionally, I suggest permitting any statement to
override/replace the assertion-level SubjectConfirmation sequence with its
own sequence. This isn't the same as saying you can have a different subject
per statement, but it allows different confirmations and potentially
different kinds of impersonation across statements. Ron suggested this, and
I think it strikes a certain balance between the current complexity of each
statement having a different subject, and still allowing some fairly exotic
stuff.

I believe these suggestions fit with the complex work items and should also
simplify the non-complex work items, which seems like a good thing.

Thoughts?

-- Scott