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] Proposal for assertion-level subjects





Eve L. Maler wrote:

> Ah, right.  I hadn't included subject confirmation info in the higher 
> level in my proposal, but it could be added optionally to the 
> assertion level, with the semantic that if it's present, any absence 
> of it at the lower level means to pick it up as a default.

this makes sense to me, although it seems like the existence of the 
top-level
confirmation element would not be sufficient to know when satisfying it is
sufficient to confirm all the statements.

Absent some additional control bit to indicate when this is the case, it 
would seem
that confirmation would need to proceed one statement at a time 
(independent of
whether there is a top level confirmation element.

Also if you add the the control bit (to all confirmation elements within 
the statements),
I think the value of the top level element is less clear.

>
>     Eve
>
> Scott Cantor wrote:
>
>>> One of the benefits that I was looking forward to with 
>>> assertion-level  subjects was only having to confirm the subject 
>>> *once* in the common  case, and I'm not sure how that is impacted by 
>>> this proposal.
>>>
>>> In the presumably common case that there is one SubjectConfirmation  
>>> method that a number of statements share, does this proposal allow 
>>> an  assertion-level expression of that method?
>>
>>



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