OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-core message

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


Subject: Re: Assertion Validation Service


Hal,

I believe that the question of assertion validation goes beyond
PKI issues. Here are some thoughts on this matter:

  Today, attribute authority-like things within enterprises tend to be
considered by relying parties as authoritative for all information they
emit.  But in a federated system, a given AA may be trusted for certain
attributes that it issues and not for others.
  I'll again  use the notion of a clearinghouse.  A relying party might
consider the clearinghouse AA as authoritative with respect to some
sources but not others. Given that one possible attribute query is
"Give me all the  attributes for the following principal", the relying
party might wish to pick and choose among the attributes it receives
back.

  This sort of "attribute validation" mirrors real life (well, my
life :-)). There are people I trust to give me certain sorts of
information but not other types of info.
  There isn't anything spooky about this -- it is just that some
people tend to exaggerate and/or distort in certain areas.
  Here's a specific example: I had a marketing person who though
basically  competent was totally unreliable when it came to the Federal
systems market.  Why?  She never did her own research, but instead just
passed on the pronouncements of the notoriously flaky Federal Systems
sales guy.
  Why she did this is a whole can of worms, but suffice it to say, that
I learned to regard her information about the Federal market in a
different way than I did her info for other markets.

  I believe that in a truly federated system, a relying party will
want and need to go through a validation process on the information
*in* an attribute assertion.  This strikes me as quite different than
validation of authentication information about the asserting party.
(I tend to think of that as "around" the assertion.)


Regards,
Marlena



Hal Lockhart <hal.lockhart@entegrity.com> on 04/13/2001 04:17:02 PM

To:   oasis sstc core <security-core@lists.oasis-open.org>
cc:
Subject:  Assertion Validation Service



The notion of an assertion validation service is floating around and
appeared on the ballot, but it is not clear to me that there is significant
agreement on what it means.

Phill suggested that it is something like X-KISS. If so, I suggest it be
called a PK validation service or something of that sort, since it is not
validating assertions, but the cryptographic operations used to bind the
assertions to its issuer and/or subject.

Assuming this is what is intended, I see two issues.

The first is procedural. In my mind this is a major change of scope in SAML
and should have been presented to the rqmnts group in the form of a use
case
or rqmnt. It certainly seems to me to be more like a business rqmnt than a
technical mechanism, as it implies various characteristics of the client
systems and networks not mentioned in any current use cases.

The second issue is more significant. As I understand it, XKMS (which
subsumes X-KISS) has just been submitted to the W3C. It does not seem wise
to have two different standards groups working on the same standard at the
same time. The obvious resolution would be to have SAML simply reference
X-KISS. This is ok with me, but we are faced with the same problem as with
XML encryption. (Debated and balloted in the rqmnts group) It may not be
completed in time for SAML. It seems impractical to reference something
which does not exist.

I have not been involved with XKMS. Perhaps it is destined to be swiftly
ratified with little or no modification. That would eliminate the problem.
Can anyone comment on this?

Hal

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: security-core-request@lists.oasis-open.org




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


Powered by eList eXpress LLC