On Mon, Aug 13, 2012 at 7:12 AM, jleleu <lel...@gmail.com> wrote: > Hi Matt, > > Thanks for your feedback. > > I agree with you on LOA definition but CAS is not dealing with > registration process but authentication procces, so LOA I talked about must > be seen as a LOAA : Level Of Assurance in Authentication. >
Agreed -- and perhaps we can map the LoAA and Authentication Handlers to the SAML Authentication Method Identifiers in section 7.1 here?: https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf > > I still believe a numeric value is appropriate for it, as levels of > assurance can also be given multiple names. So I imagine we can have (just > to give you a silly example) : LOA4 (value = 30, names="NIST_Level2", > "IAP_Bronze"). I think of numeric value as internal LOA for CAS server and > names as public standards references. > > I argue this only from our own scenarios compared to your current ranking -- as a single example, for us, a Remember Me cookie is probably /stronger/ than an IP, given that we NAT a significant part of our wireless network. However, I understand that would not necessarily be true for all deployers. I would think it very difficult to develop a system that can compare the strengths and weakness of each method in a relative numerical fashion, meeting all CAS deployers needs. Admittedly, I am thinking about this in a Federation sense, where we all agree to common values. If these values are free to change by each deployer, with no need to maintain commonality across deployers, perhaps this is not important. I'm not sure to understand if you find something wrong in the spec and if > so, what do you want to change and how ? I expect discussions on this > thread to be *also* more concrete and more focused on concepts and spec > parts. > > About the two options you propose and your recommendation (#2), I think I > agree with you and the spec should be more precise on responses to client. > I present LOA as *requested* from client or by CAS server definition and > not as *computed* to be returned to client. Proofing and authentication > attributes should be returned to client (and certainly *effective* LOA > also). > > I think section IV, use of the "renew=name", could be expanded. Perhaps it shouldn't be an LoA that is requested (since LoA requires proofing assurance), but just an Authentication Method (or list of acceptable authentication methods), ideally using the values in the SAML spec. Authentication Handlers then register one or more Authentication Method Identifiers, and deployers could map Authentication Method Identifiers to custom authentication handlers. Uniform use of the SAML Identifiers would let clients perform authorization on the authentication method, and request a specific authentication method (or set of authentication methods) from the server, in a consistent fashion. Note well -- I am nitpicking on detail of the naming specification and relative comparison process. In general, I think the writeup is very good. -- m...@forsetti.com PGP: E2144AD8 -- 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
