On Fri, Nov 16, 2012 at 10:02 AM, Robert Oschwald <robertoschw...@googlemail.com> wrote: >> 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. > > I've copied over my wiki page for the 3.0 Specification to a Google Docs > document. > Everyone can read it. > > Currently, Marvin, Jerome and I can write. > > Everyone else who wants to have write access, please write a quick note here.
Please add wgt...@gmail.com. Let's keep the communication level high on cas-dev list as well. Thanks, Bill > > Link: > https://docs.google.com/document/d/1l0o60mLfXF4bkQdwRSH4i6P-IJQki3-v-zyoOAjxDd4/edit > > Robert > > > Am 16.11.2012 um 14:53 schrieb "William G. Thompson, Jr." <wgt...@gmail.com>: > >> 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
