RE: Resend: ISSUE:[UC-8-0*:Intermediaries*]

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

I think these documents re-enforce my belief that we should keep the rules
for altering assertions as simple as possible. If we provide a lot of
complex add, subtract, modify functionality, given the variety of
configurations and applications that will be supported in the XP world, it
is a near certainty that somebody will misuse SAML in a way that creates
security risks. Even stating the security considerations will be difficult.

If the rule is: Authorities create immutable Assertions, other Authorities
can add their own Assertions, anybody can discard an Assertion, then it will
be easy to understand and hard to misuse. Does anyone have a specific use
case that this breaks?

Supporting a more complex scheme will also complicate the design and
implementation. Likely every assertion will have to sign every component
individually, just in case somebody wants to remove one of them. Its usually
not a good idea to make the common simple case complex in order to
accomodate rarely used functionality.

The other issue about Intermediaries is controlled delegation. I don't
remember if it was after Dave left, but at the F2F I deliberately asked
about delegation in the hope of provoking the reaction I got. Bob Blakely
commented "Delegation is the spawn of the devil." I agree with Bob, although
perhaps not for exactly the same reasons. Most people who have been down
that road also have scars.

Finally as to the XP design itself. It looks to me like they are digging
themselves a big hole. It seems like they are not only designing an
application protocol, but also reimplementing TCP. Maybe you just convinced
me to vote for a SOAP binding. ;-)

Hal

> -----Original Message-----
> From: Orchard, David [mailto:dorchard@jamcracker.com]
> Sent: Wednesday, March 21, 2001 12:46 AM
> To: security-use@lists.oasis-open.org
> Subject: Resend: ISSUE:[UC-8-0*:Intermediaries*]
> 
> 
> Sorry, I accidentally hit some random keys whilst pasting 
> into the message
> that caused it to be sent.  I resend with the actual content 
> I desired.
> 
> I am baffled that this has not generated more discussion.  The role of
> intermediaries and security on XML Protocol has been going on 
> for months
> now.
> 
> I would have liked to see more discussion on our domain 
> model/abstract model
> on this concept.  I show the following links to illustrate 
> XP's discussion
> of intermediaries as it seems extremely relevent.
> 
> [1] http://www.w3.org/2000/xp/Group/xp-reqs-05.html#fig1 
> Requirements doc
> showing intermediaries
> [2]
> http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/att-0
> 066/01-01-03-1
> 3-an_abstract_model_for_intermediaries.html
> [3]
> http://www.w3.org/2000/xp/Group/1/02/13-abstract-model/XMLProt
> ocolAM.html
> shows the XP abstract model.  Section 3.3 talks exclusively about
> intermediaries.  
> 
> There is a good definition of an XP Intermediary in the XP 
> requirements doc,
> which seems equivalent to a SAML intermediary:
> XMLP intermediary 
> An XMLP intermediary is both an XMLP receiver and an XMLP sender,
> target-able from within an XMLP message. It processes a defined set of
> blocks in an XMLP message along an XMLP message path. It acts 
> in order to
> forward the XMLP message towards the ultimate XMLP receiver.
> 
> Some questions I have:
> 
> What other operations are permitted or not permitted at the 
> intermediary?  
> Can it change the target?  
> What if the message is a SOAP message with Attachments.  Can 
> the attachments
> be changed/added/deleted?
> In what cases is it not really an intermediary, but really a 
> chain of 2
> different SAML requests?  My question is at what kind of 
> operations on the
> request is it no longer considered a modification of a 
> request but a whole
> new request.  8.4 Seems exactly like this, there is no "Edit" 
> of the SAML
> request, it's a whole new request.  
> How is an intermediary "targetted" by the sender of the SAML?
> How is a SAML intermediary different than an XP intermediary?  Are we
> duplicating effort?  How are we "distinct"?
> 
> I have more questions, but I'll stop there as it's late.
> 
> Cheers,
> Dave Orchard
> XML Architect
> Jamcracker Inc.,    19000 Homestead Dr., Cupertino, CA 95014
> p: 408.864.5118     m: 604.908.8425    f: 408.725.4310
> 
> www.jamcracker.com - Sounds like a job for Jamcracker.
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-use-request@lists.oasis-open.org
>