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



Scott Cantor wrote:
>>- The use case of an assertion with multiple statements having
>>   multiple subjects is unrealistic at this time.  It would be
>>   simpler to do away with it.
> 
> Another key point was that, as Bob noted, we take pains to emphasize that
> there is no special importance attached to grouping statements in an
> assertion. Two statements in one assertion is the same as two assertions, if
> the other conditions and so forth match. So the point is to optimize the
> common case, not the uncommon case.

Sorry, I meant to add a mention of this to the proposal, but forgot. 
The way I was thinking about this was: "Boxcarring" information in a 
single assertion isn't supposed to have any additional semantics that 
separate assertions would have, but that this doesn't prevent us from 
reducing options in the single-assertion case that are available in the 
multi-assertion case.  It nets out to the same thing that you say above...

>>- English: Allow a series of zero or more "naked"
>>   SubjectConfirmation elements in Statements.  (XSD-speak: Remove
>>   the SubjectConfirmation element from the content model of
>>   SubjectType, base the three major statement types on
>>   StatementAbstractType instead of SubjectStatementType (which
>>   would itself be removed as dead code), and reference
>>   SubjectConfirmation as an optional repeatable element inside
>>   StatementAbstractType.  Put some prose around what it means to
>>   have multiple subject confirmations on a statement.)
> 
> Ron also proposes adding a NameIdentifier (of whatever type) to that element
> so that the confirmer (attester) can be named. This (together with a
> suitably changed holder of key method or a new confirmation method entirely)
> provides for fairly explicit impersonation.

I left this out because it's specific to the subject confirmation topic 
rather than to the assertion-level subjects topic, but yes.

>>- English: Push the Subject element up into Assertion as a
>>   required field, but make sure that people can still create
>>   subjectless assertions if they wish.  (XSD-speak: Change
>>   AssertionType to AssertionAbstractType and derive a new
>>   SubjectAssertionType from it that contains a required Subject
>>   element after the Issuer element.  Base the Assertion element
>>   on SubjectAssertionType.  (This is on the theory that all of
>>   SAML's three main statement types currently require subjects
>>   anyway, and that we have a StatementAbstractType-to-
>>   SubjectStatementType hierarchy now.))
> 
> I was a little more uncomfortable with this before than I am now, but am
> still feeling a little queasy about it. Mostly because I think once you
> follow this through, we'll still end up with no way to enforce (in XSD)
> that, say, an AttributeStatement, can't appear in one of those
> "subject-less" assertions.
> 
> I guess we could divide up the statement types into a SubjectStatementType
> hierarchy and a SubjectlessStatementType hierarchy (of which we have none)
> and not connect them. So you'd have one type of assertion that carries only
> SubjectlessStatement-derived elements and one type (ours) that carries only
> SubjectStatement-derived elements. As soon as you mix them, you're right
> back to the same ambiguity again.
> 
> Otherwise, I'd just as soon leave it in prose, make Subject optional, and
> say that the three statements we have cannot appear in an assertion without
> a Subject. That's easy to check (though not at validation time).
> 
> Also, I just brought this up in an email, and maybe my grammar's a bit
> rusty, but....on some level, is it even possible to make a statement without
> a subject either implied or explicit? Does not every English sentence
> (statement) have one? If that's just a stupid thought, I blame the Nyquil.

(Ah, Nyquil, my drug of choice. :-)  I'm less paranoid than you about 
this, though now I understand the part that you were saying might be 
inexpressible in XSD.  The semantics of arbitrary SAML elements mixed 
together in novel ways are undefined.  People could pick apart and 
recombine SAML elements today in weird ways, but they don't.  I prefer 
the proposal as originally outlined to a prose-only solution that 
involves optional Subject elements.

I believe all natural language statements have subjects, though some are 
interestingly buried or implicit.  If we're all agreed on this, we can 
perhaps do away with subjectless assertions!

	Eve


-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com



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