[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] Issue 250: ValueType --> TokenType+ReferenceType?
Thomas, This msg is in response to the issue 310 related aspect of this thread. DeMartini, Thomas wrote: >] >It is my understanding that in 310 we would be allowing multiple STRs >in >] >one KeyInfo. Certainly I would not have agreed to put multiple >] >references within an STR. In fact, doing so would completely >invalidate >] >the saml tp. >] > >] > >] We are getting a bit off the track here, why does it make a difference >] wrt to invalidating >] whatever profile, whether we expect them to be be aware of the >potential >] for multiple >] STR's in keyInfo, or multiple reference forms within STRs? >] >] One benefit of multiple reference forms in STR's, is that it allows >for >] alternate references >] wherever STR's can be used. Not just in keyInfo. > >Because the saml tp already utilizes the multiple children aspect of STR >to carry the saml:AuthorityBinding together with the wsse:KeyIdentifier, >overloading the semantics of those multiple children of an STR to mean >multiple equivalent references would create a normative conflict. > The STP currently requires that a keyIdentifier be used in an STR, that it take a specific form, and that it be supported by an AuthorityBinding element if the token is remote. These requirements do not preclude the inclusion of other/optional reference forms in an STR that references a SAML token. For example an STR could include a keyIdentifer with a supporting AuthorityBinding element, and a Direct reference with a contained URL. The optional inclusion of a direct reference in addition to the required keyIdentifer, would parrallel my suggestion that we allow the optional inclusion of thumbprint based KIDs in addition to a required to be supported reference form. In the case of the STP, there will be changes in the permitted reference forms (as a result of the update to 1.1 core to allow local direct references by assertion identifier). In making those changes it would, IMV, be appropriate to reword the requirements around keyIdentifiers, such that they no longer preclude the inclusion of other forms of keyIdentifiers in addition to the one that implementations are required to support. I think all the profiles should be re-released with V1.1 core. Ron
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]