Am 04.11.2013 um 10:16 schrieb Jérôme LELEU <lel...@gmail.com>: > I'd prefer we start a new CAS 3.1 revision to receive enhancements. > +1 but I recommend we name the next version 4.0 to be inline with the current CAS Server version.
Also, I plan to state Jasig CAS as the official reference implementation into the specification. > There are several other things that could go also in a future revision : > - multi-values attribute (CAS-1283, > https://groups.google.com/forum/?fromgroups#!topic/jasig-cas-user/Ir9rcCuPgz4) > - authentication attributes like isFromNewLogin and authenticationDate. > +1 > About testing, I think the RCx and GA are made for that as the CAS server > always responds in a CAS3 protocol way. I've made tests for the Java CAS > client and it works. > Great. Bill stated that we need to cover additional clients. Are we the maintainers of the .NET client and phpCAS as well? Also, we shouldn’t forget the ColdFusion CAS Client, which some of my clients are using. Best, Robert > > 2013/11/3 Robert Oschwald <robertoschw...@googlemail.com> > > > > > 1. Clarify some language around proxy protocol parameters. > > Yes. > > > 2. Add some descriptive language for how use of proxy-granting tickets may > > affect lifecycle of parent (granting) tickets. This would hopefully provide > > some guidance for implementation considerations around CAS-1349. Ideally we > > would be prescriptive here, but at a minimum we should provide a discussion > > of implications of various strategies and offer best practices. > > This is an ongoing, optional implementation and we are not sure if we > backport this into 3.5.x, yet. I will add some wording about that feature > into the 3.0 spec today as an optional parent ticket lifecycle influence. > > > > 3. Add a ticket parameter to the /logout URI to selectively destroy a > > single ticket (and its children); if no parameter is provided destroy the > > root TGT that holds the SSO session and all child tickets. I see this as > > complementing #2. > > > > Thats something for the upcoming CAS 4.0 spec I will start right after 3.0 is > released. > 3.0 is the status quo for CAS2/3 implementations, therefore I recommend that > we finalize and release this spec asap. It took a while now but I would > prefer we finish the 3.0 doc without adding new features. There are already > requests in CAS-1284 for a CAS 2.0 / 3.0 spec. > > One motivation for the 3.0 Spec as a first step to 4.0 was, that a lot of > features we have in CAS 3.0 are not backed by a formal specification. It is > currently very hard for new developers to get into the CAS 3.0 features due > to this. They need to read through mailinglist posts and several wiki > documents to get a clue. > > > I think the protocol as it stands is looking good, and I hope there is time > > and energy to consider the concerns above before we finalize. > > > > I believe it's a separate matter, but important and related, whether CAS4 > > should default to new views that support v3 by default at the existing v2 > > URIs, most importantly /serviceValidate. I think there's reason to be > > concerned about backward compatibility with existing clients for which we > > need more than "trust me" to move forward. If anyone has done integration > > testing to that effect with positive results, please speak up; otherwise > > such testing needs to be completed before we ship 4.0 final with the > > present defaults. > > > > +1 > > > > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: lel...@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: > robertoschw...@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-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
