RE: Contradictory requirements?

[Tim Moses <tim.moses@entrust.com>]

Title: RE: Contradictory requirements?

Evan -

<ESP wrote>< ...

Is that what you're suggesting? I wonder if you could maybe draw it
out and submit a draft document to the bindings group for comment.

~ESP

P.S. As to trust between partners: yes, even though W.S. N may trust
W.S. N-1, it may not trust W.S. N-2, N-3, dot dot dot. It seems like
the proper way to deal with this is to have two kinds of trust: one
where W.S. N trusts W.S. N-1 to authenticate users directly and pass
on those users, and one where W.S. N trusts W.S. N-1 to handle
third-party assertions and users correctly. That is, N trusts N-1 to
give trust correctly.

...></ESP wrote>

Yes, that is exactly what I'm suggesting, and I would be happy to write it up for submission to the bindings activity.  However, it will have to wait until Tuesday, as I will be on vacation from now until then.

The "basic auth" and "cert" solutions (that you mention) aren't applicable, because basic auth doesn't give single-sign-on and, if we had used certificates in the first place, we wouldn't be in this mess ;-)  Therefore, I will propose a cookie solution.  My one residual concern is that a cookie solution violates the second sentence of the [R-Intermediaries] requirement.

Of the two suggestions in your postscript, I don't like the first (making daisy-chainning illegal), because I believe we want to support daisy-chaining.  And I don't like the second (every link WILL be trusted) because (regardless) assurance is eroded at every link, and the final relying party cannot even see how long the chain is, let alone who is in it.  So, it is unreasonable to expect the relying party to make an informed decision concerning the assurance it should place in the binding between the assertion and the browser.

Have fun in The Valley.  I'll be thinking of you all (not).  Best regards.  Tim.