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


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

It never is. There's no way to confirm all the statements, only confirm each
statement and happen to cache the fact that all of them point back to the
common method so you don't repeat the process.

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

I don't think the bit matters, you always confirm statements because
assertions themselves make no claims to evaluate.

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

The purpose is to optimize the common case and not repeat the whole thing
with multiple statements.

As usual with this defaulting idea, the edge case is how to say there's a
default confirmation and then override it in a statement to say "no
confirmation", but one could simply rule that out and say you can't default
it in that case. Again, not common, so it doesn't seem a big deal to me.

-- Scott



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