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

[Paul Madsen <p.madsen@entrust.com>]

thanks Scott, with respect to time windows for confirmation and validity,
can we formulate some guidance on how the two intervals must relate. For
instance, can 

1) a subject confirm themselves to an assertion that is not yet valid?  
2) a subject confirm themselves to an assertion that was valid but has since
expired?

paul

>-----Original Message-----
>From: Scott Cantor [mailto:cantor.2@osu.edu]
>Sent: Tuesday, May 25, 2004 2:17 PM
>To: 'Paul Madsen'; security-services@lists.oasis-open.org
>Subject: RE: [security-services] Comments on Core 13 & Profiles 08
>around SubjectConfirmationData
>
>
>> 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
>