OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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


>-----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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]