Hi, I'm in line with Robert, we should finish the spec (and the CAS server 4.0.0) ASAP. I'd prefer we start a new CAS 3.1 revision to receive enhancements.
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. 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. Best regards, Jérôme 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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
