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

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

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

-- Scott

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