> Ok. I think I got it now...thanks for catching us (me :) up on the > thread. Let me see if I can summarize: > > * CAS Protocol 3.0 rev is simply meant to capture current, > in-the-field, practice that has evolved in CAS3 and the respective CAS > clients. (e.g. the <cas:attributes> customization) >
correct. > * Most CAS clients (including the older Spring CAS client) already > support arbitrary attributes under <cas:attributes>. > correct. > (Additionally there was some consensus on cas-dev regarding the desire > to indicated authN metadata vs user attributes for the evolving LOA > feature...thus the addition of the embedded <cas:userAttributes> to > the <cas:attributes> block as well as tags for authN metadata in the > example response. All of these attributes are optional since they > appear in <cas:attributes> and not likely to be implemented until LOA > is truly worked out. correct. > Perhaps the example response could be simplified > to better reflect current practice and to avoid confusion?) > In the WIP 3.0 document, I added the userAttributes in the example xml just to show that even that response is fully schema compliant. If this irritates people to much, I remove the userAttributes for now. > For the CAS Protocol 3.0 rev, all we are saying is that > <cas:attributes> and anything under it is optional and that clients > may make those available (likely via a principal object). Yes? > correct. <cas:attributes> is optional and additionally, any extra child Elements within it which are not defined in the xsd can be freely added by the implementor without breaking schema validation. > So for https://issues.jasig.org/browse/CAS-1283 all we need to do is > add something simliar to CAS-655 and verify it works with current > clients? correct and +1 Robert -- 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
