[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