RE: Proposed glossary definition of 'Assertion'

[Hal Lockhart <hal.lockhart@entegrity.com>]

I like the idea of two defintions. informal/technical, layman/wonk come to
mind as expressing the dicotomy.

Should one of the definitions include the idea that the Authority is
considered and authoritative source of this information by some set of
relying parties? It seems a little feeble to just say "declaration" or
"claim being asserted". Perhaps this notion should go in the Authority
definition?

I do not understand the intent of the parenthetical part of "they may be
signed by some authority (not necessarily the Asserting Party)." What case
do you have in mind? If the Authority in question is implmented as several
distinct components or even if the digital signature function is outsourced
to a different organization, *which has no other role in SAML*, then I would
consider the aggregate of these components to constitute the Authority from
a SAML architecture or definitional perspective.

Another way of saying the same thing is that we have a limited number of
active entities defined in SAML and everything else is outside of SAML. Each
entity is considered a black box. In my mind the entity that signs the
assertion is the authority. Surely you don't envision a PEP signing an AuthN
Assertion or an AuthN Authority signing a AuthZ Decision Assertion?

Hal

> -----Original Message-----
> From: Jeff Hodges [mailto:jhodges@oblix.com]
> Sent: Wednesday, April 25, 2001 8:04 PM
> To: security-services@lists.oasis-open.org
> Subject: Re: Proposed glossary definition of 'Assertion'
> 
> 
> Irving Reid wrote:
> >
> > Assertion: A datum that contains (a) The principal identity 
> of the Asserting
> > Party, (b) An identifier of the referent of the assertion, 
> and (c) the claim
> > being asserted. Assertions may also have Assertion 
> Identifiers, and they may
> > be signed by some authority (not necessarily the Asserting Party).
> 
> I think this is a good suggestion - thanks Irving. Tho it 
> does bring up some
> other thoughts..
> 
> This def seems to me to constitute a particular design for an 
> assertion. As such
> it's nominally ok-by-me as long as it's the actual design we 
> decide upon. But
> I'd hesitate to use this as the entire def for something like 
> "assertion".
> 
> It seems to me that we may want to have two "senses" for 
> definitions of SAML
> protocol artifacts ("assertions" being one specific example): 
> one sense being a
> plain-language definition describing the kind of thing it is, 
> and the other
> sense being a specific-to-saml technical definition like the 
> one above. 
> 
> I think having both senses will help our spec be more 
> accessible to a wider
> audience.
> 
> 
> So for "assertion", we'd have something like..
> 
> (1) a piece of data constituting a declaration of some 
> information, for example
> about state ("so-and-so" is "authenticated") and/or 
> attributes ("so-and-so" is
> of the type "pink"). 
> 
> (2) A SAML assertion is a datum containing (a) The principal 
> identity of the
> Asserting Party, (b) An identifier of the referent of the 
> assertion, and (c) the
> claim being asserted. Assertions may also have Assertion 
> Identifiers, and they
> may be signed by some authority (not necessarily the Asserting Party).
> 
> 
> Plus we SHOULD ensure that the glossary has defs for the 
> SAML-specifc, technical
> terms used in (b)..
> 
> Principal identity
> Asserting party
> claim
> assertion identifier
> authority
> 
> 
> JeffH
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-services-request@lists.oasis-open.org
>