On Wed, Nov 14, 2012 at 9:42 AM, Jérôme LELEU <lel...@gmail.com> wrote: > Hi Robert, > > No problem for the delay. No pressure... > > From my point fo view, we have data : authentication and user information > and we have formats to send this data : plain text (CAS1), xml (CAS2), SAML, > JSON... > > I think we need the distinction between user and authentication attributes.
+1 > > I prefer to be too permissive on user attributes definition in XSD else it > would be hell for CAS deployers to update XSD every time they want to return > a new attribute. +1. Let's make sure we take into consideration this use case....deployers come first in my book. > > The SAML validation should be part of the spec, but marked optional as we > decided some times ago. Making SAML optional makes me wonder about the SAML > validation in CAS client : make it optional also ? split the CAS client in > multiple specific clients ? Personally, I think we should defer any SAML discussion to the SAML spec. I'm also in favor of deprecating the SAML1.1 end-points in favor of the new CAS+attributes payload. > > Adding JSON validation in the spec was just a proposal : we need to decide > on this. +1 > > For LOA, I'm not very optimistic in our ability to do it quickly so I think > it will be out of scope for this spec revision. Robert, how about we start a shared Google Docs for the protocol rev? This would facilitate collaboration and likely get us to the goal sooner. Best, Bill > > Best regards, > Jérôme > > > > > On Wednesday, November 14, 2012 10:30:49 AM UTC+1, Robert Oschwald wrote: >> >> Jérôme, >> >> thanks for your comments. I appreciate it. I'm late in replying because I >> was on vacation and be busy currently with 2 big projects. >> >> All obvious points you mentioned I will introduce. >> Some I think we need to discuss further: >> >> Attributes: >> I added an "xsd:attributes" element because that is widely used (e.g. in >> Java CAS client) and did not distinguish between user and authentication >> attributes because of this. >> Maybe it would be a good idea to encapsulate all user attributes in an own >> "userAttributes" parent within the "attributes" Element. I think of it a bit >> more. >> >> User attributes xsd restriction: >> When we would allow any user attribute elements in the xsd we define in >> the spec, we cannot restrict the sub structure of them (e.g. <xsd:any /> >> allows arbitrary sub structures. You cannot restrict to single level >> elements in xsd) >> Also, as we define a CAS specification, we should set the schema >> restriction to the common, base elements needed so any CAS client or server >> can be implemented compliant to this specification. >> This does not mean that one is not allowed to extend the response schema >> to his needs in the concrete implementation (thats what we and others have >> done in the past, eg for rememberMe notification support). >> What do you think? >> >> samlValidation: >> Regarding samlValidation, I would add it to the spec but mark it as >> optional, as this is the standard validation way this times (e.g. in CAS >> Client, Spring Security). I'm absolutely open to a discussion here. >> >> jsonValidate: >> I wasn't aware that currently external extensions should be part of this >> spec. I think jsonValidate is of great value, but shouldn't we also add this >> feature to JASIG CAS code base, so we support all the features described in >> the spec and document it in the CAS user manual ootb? >> >> Regarding LOA: >> I know this is an ongoing task to implement it currently. I'm not into LOA >> that deep, so I would appreciate if you can add this chapter (you got write >> access to my page) or give me some pointers to documentation so I can add >> it. >> >> As I'm in 2 big projects currently, it will take some time until I can >> work further on the spec. Please be patient with me. >> >> Best regards, >> Robert >> >> Am 23.10.2012 um 13:08 schrieb jleleu <lel...@gmail.com>: >> >> > Hi, >> > >> > It'a great work Robert, changing the CAS protocol has a much wider scope >> > than I thought. >> > >> > My comments : >> > >> > - /login as credential requestor : I don't see the "method" parameter to >> > define how to do the redirection to the requested service after successfull >> > authentication (method=POST) >> > >> > - parameters for username/password authentication : OK for the >> > rememberMe parameter >> > >> > - "service" parameter on logout : OK, but you need to add that for >> > security reasons, the "service" parameter must match a configured CAS >> > service >> > >> > - single sign out : there is nothing about front channel SLO, we should >> > maybe anticipate this... >> > >> > - /serviceValidate : I don't see authenticationDate and >> > longTermAuthenticationRequestTokenUsed attributes as *user attributes*, >> > they >> > are authentication attributes from my point of view. They need to be >> > returned outside the user attributes tags. For the user attributes, I >> > wouldn't be so retrictive and allow user attributes of any name. >> > >> > - /samlValidate : we said that the SAML validation will become an >> > optional module (CAS-1188) : should it be part of the spec ? At least, the >> > optional aspect of this validation should be added in the spec. >> > >> > - /jsonValidate : you don't mention this new endpoint url, Dmitriy won't >> > be happy here ;-) >> > >> > - I don't see anything about loa. Is it on purpose ? >> > >> > I think that this topic will also deserve a conf call to reach an >> > agreement some day. >> > >> > Are steering commitees still happening some times ? I think it would be >> > the right place to focus on these topics : LOA, CAS protocol revision... >> > >> > Best regards, >> > Jérôme >> > >> > -- >> > You are currently subscribed to cas...@lists.jasig.org as: >> > roberto...@googlemail.com >> > To unsubscribe, change settings or access archives, see >> > http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> >> -- >> You are currently subscribed to cas...@lists.jasig.org as: >> cas-dev-gar...@googlegroups.com >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> > -- > You are currently subscribed to cas-dev@lists.jasig.org as: wgt...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- 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
