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.
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?
>
>
> I think that has to be part of the solution, or we lose much of the benefit.
>
> In fact, it seems clear to me that Subject as currently defined is really
> one of two things:
>
> An identifier + optional subject confirmation
> or
> subject confirmation
>
> That suggests that what we're really doing is giving assertions a single
> subject identifier (via a choice of BaseIdentifier, NameIdentifier,
> EncryptedIdentifier) and then separating out subject confirmation from that.
> So Subject per se is gone.
>
> My assumption is that SubjectConfirmation itself becomes a sequence of
> elements, each one containing an optional identifier, a method, and
> method-dependent data.
>
> The sequence would appear both in the assertion (following the subject
> identifier) and in each statement.
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 354 9441
Web Products, Technologies, and Standards eve.maler @ sun.com
