[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Subject/SubjectConfirmation proposal
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]