> My point here is that you start with lot of details about the > authentication (identity validation info, policies, mechanism, transports, > key strength, timestamp, etc.) and you need to digest them down to > something simpler so you can make a decision.
I believe most of what you mentioned are a priori details known to both relying parties as a matter of security policy in the environment as a whole. For example, we issue hardware tokens that have well-known identity vetting and cryptographic properties (e.g. key strength). If the client is told that the user has authenticated with a token, which we do presently via an loa attribute and SAML authentication method URN, then the client has a very high degree of assurance that the user is who he claims to be. I think it's fair to say that uses cases like this are fairly common in Higher Ed if not generally; arguably the normative cases. I'm open to the idea that for some kinds of assurance use cases more information needs to be transmitted between relying parties, but I'm fairly certain it's an edge case. I'm hopeful we can design for most use cases with a simple yet extensible protocol, then extend toward edge cases as they arise. M -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
