Hi, @Nathan : Go ahead, don't hesitate to update the wiki with your own comments / changes, just use a different color and add your name, so we can see your remarks before we agree and replace the original spec.
Just a single attribute to define the "supported level of assurance" may seem to be limited, but I had in mind to use the supports method of the authentication handler to handle password strength issues. Example : authentication_handler1 : bind on LDAP, supports method supports only password length >= 4, LOA = 10 authentication_handler2 : bind on LDAP, supports method supports only password length >= 6, LOA = 20 Do you think it's sufficient ? @Matt Like Nathan, feel free to update the wiki with a specific color and your name. Using SAML authentication method identifiers is a good idea, but how do you request different password strengths with the same name of authentication handler (urn:oasis:names:tc:SAML:1.0:am:password for example) ? I think there is a need for being able to request a set of authentication handlers (this one and more secure ones) and ranking was a good mean to do that, but you're right about ranking, it needs to be defined for each CAS deployment. On the other hand, removing LOA numeric value could be a good way of simplifying the spec : no more assurance policy and LOA, just an "authentication policy" defining which SAML authentication method identifiers (SAMI) maps to what authentication handlers and just one new syntax for renew parameter : renew=sami1|sami2|sami3 (sami1 or sami2 or sami3). There is an important issue here : keep assurance policy / LOA or request explicitely SAMI ? Thanks. Best regards, Jérôme -- 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
