RE: [security-services] Comments on Core 13 & Profiles 08 aroundSubjectConfirmationData

> 1) Core schema doesn't currently allow for these NotOnOrAfter 
> & NotBefore (nor the others) attributes on 
> SubjectConfirmationData, the schema for which is
> 
>  <element name="SubjectConfirmationData" type="anyType" />

That's arguable, since anyType implies anyAttribute (though many parsers get
this wrong). However, on the call I suggested we define a new type to
contain those attributes and reference it from profiles.

> 2) Logically, the attributes NotOnOrAfter and NotBefore seem 
> inconsistent with the above definition for 
> SubjectConfirmationData, i.e. they are conditions on the 
> confirmation rather than data to be used for that confirmation. 

I think these amount to one and the same, and a key is essentially a
condition on confirmation of HoK, but that's semantics. Will look at text to
see if it can be generalized a bit.

> 3) What is the relation between these NotOnOrAfter and 
> NotBefore attributes on SubjectConfirmationData and the 
> attributes of the same name on the Condition element. What 
> would it mean for an assertion to be valid for some interval 
> (as defined by the times specifed in the Conditions element) 
> but during which the Subject can't confirm itself (as 
> specified by the times on the SubjectConfirmationData element)?

This was discussed on call. An assertion could be valid without a particular
entity being able to confirm itself as the subject. Some profiles/uses may
not require that the entity using it can confirm itself as the subject.

This is in fact what forwarding a SSO assertion would be, and people do that
today, so this proposal attempts to draw a line between these two issues.
You can confirm as bearer for 5 minutes, but the SP can do X/Y/Z with it
until some later time bounded by the issuer.

-- Scott