> > Those are all *application* layer questions, but having the certificate > information available makes it possible for me to have a high level of > confidence in the identity, which I will use in the application layer for > this kind of policy enforcement. > > This is all about making life easier for application developers. > Now, we have the following hierarchy: G -> A -> B Where G is user "garrett". Now we authenticated user garrett at A, but we can't be confident that request is made by garrett at B because A doesn't have garrett's certificate. That all said given that TLS is only possible for hop-by-hop security not end-to-end. So in your case end-to-end security validation must be done by application anyway. You are correct. I can only authenticate my immediate peer. For many applications, this is all that is needed. It won’t support richer device patterns, although one can imagine building configurations where an edge router on the network receives requests, performs the authentication, and then ships them off to an internal service following the device model, but extending that to add information about the authenticated user. Its not possible to do this with device off the shelf, but not hard to build either, and its a well-understood architecture. However, I’m also thinking of some “tunneling” approaches where SP is used as a transport to fabricate a stream (making full use of rich hop-by-hop routing in SP), and on top of that virtual stream, we run TLS, and inside that TLS tunnel we can get end-to-end security. This is sort of like an SP-specific VPN. Basically, SP becomes an application layer protocol on top of itself with some crypto sandwiched in between. :-) - Garrett