RE: Assertion Validation Service

[Philip Hallam-Baker <pbaker@verisign.com>]

I think I agree with everyone (if that is not contradictory), at least on
the technology. 

In general I think that *ANY* requirement is fair game to throw at the
assertion group from the point of "can we use the framework to cover this
case, if so what extensions are necessary and what might they look like".
That does not mean that the proposal makes it into the SAML 1.0 spec, but it
means we do think about it to make sure we don't build ourself into a
technical dead end or miss some important generalization.

In the ESA requirements analysis one of the consistency constraints is that
each requirement stated must be addressed and each architectural feature
must be satisfied by a requirement.

I think this is a reasonable approach, we may find that the most compact
architecture to met the requirements specified may have some additional
coverage [collateral damage], we may find that the architectural cost of
meeting a requirement is considered by the whole group to be 'too high' and
hence want to take a vote of the whole group on revising the requirements
doc. In general however the architecture group should not be building
anything whose primary function is outside the scope of the requirements
doc.


On the need for an assertion validation function, this issue is tightly
bound to the idea of assertion validity. In particular is it possible to
revoke an assertion after issue? This by necessity involves a lot more
mechanism than is currently in the SAML core assertions spec.

At present SAML clients ask a question and get to cache and rely upon
whatever response they recieve until the validity interval expires. This is
a perfectly reasonable engineering approach for assertions with validity
intervals tuned to a day or less, it is unreasonable for assertions with
validity intervals of a year or more.

I certaqinly agree on the need for assertions with very long lifetimes, I
have made a status management proposal to manage such assertions. I have not
made that proposal to the SAML group because I see it as a significant leap
in the complexity of the client implementation.

If the group does want to go forward with such a proposal I would at the
very least suggest that it be a discrete functionality tier (c.f. XKMS where
tier 1 is directory lookup and tier 2 is the validation service). In the
original TAXI proposal there were four tiers, Tiers 1 and 2 became XKMS.
Tiers 3 and 4 became XTASS.

I would suggest however that the problem space and solution space of tier 4
is much more complex and that SAML would be best served to make the easy
(ish) win at the basic level before managing revokable assertions. 

The bridge between the two specs I would see as being the <Respond> element.
A client capable of managing Tier 4 revokable assertions would specify the
fact in the respond element using either a keyword we define or a URL of the
extension schema.


In terms of where XKMS is, at present XKMS stops short of assertions. The
scope of a W3C working group is something we are currently in discussion
with W3C on and looking to put together an activity proposal package on.

I see XKMS as being a useful package in its own right, but clearly the idea
can be taken further, to Trust assertions, Generalized assertions, RDF etc.
Specifying a definite scope there will be tricky. I would see an assertion
validation service as being more appropriate for that type of working group
than the SAML TC.


I would like to get to closure on the Authorization and Authentication claim
element as soon as possible. The meta-assertion validity info is going to be
a much more general framework mechanism. I would rather be discussing it in
the context of a PKI and knowledge represenation community rather than a PKI
and security applications community.

	Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Marlena Erdos [mailto:marlena@us.ibm.com]
> Sent: Sunday, April 15, 2001 11:33 PM
> To: Hal Lockhart
> Cc: oasis sstc core
> 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
> 
> 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-core-request@lists.oasis-open.org
>

Phillip Hallam-Baker (E-mail).vcf