Hello All, Rather than hijacking the "CAS Protocol 3.0 Release Process Proposal" thread I figured I'd start a new thread for feedback.
My primary feedback relates to the format of additional attributes in the serviceValidate response. Because the CAS 2.0 protocol provided no guidance on how to return or format attributes implementers were left to their own devices and have come up with numerous incompatible ways of formatting attribute elements. In phpCAS we currently support three different structures for user attributes: "Jasig-style", "RubyCAS-style", and "Name-Value-style"). See our test-case for examples of these formats: https://github.com/Jasig/phpCAS/blob/master/test/CAS/Tests/Cas20AttributesTest.php While I agree that implementers should not be limited in what attributes are returned (including custom complex data-types), I do believe that guidance about formatting attributes is needed in CAS Protocol 3.0 so that we do not end up back in the same place we currently are -- with different CAS server implementations returning attributes in different formats. Even if the schema is left with userAttributes containing <xs:any/>, the description should at a minimum suggest how to format basic single-valued string attributes and multi-valued string attributes. I'd like to avoid the situation where one CAS-server returns a set of attributes like this: <cas:userAttributes> <givenName>John</giveName> <sn>Doe</sn> <mail>[email protected]</mail> <altMail>[email protected]</altMail> <altMail>[email protected]</altMail> </cas:userAttributes> while another returns attributes like this: <cas:userAttributes> <givenName> <string>John</string> </giveName> <sn> <string>Doe</string> </sn> <mail> <string>[email protected]</string> </mail> <altMail> <string>[email protected]</string> <string>[email protected]</string> </altMail> </cas:userAttributes> If implementers wish to add attributes formatted in other ways to cover complex data types that could be fine, but at least this common base case should be documented in the protocol so that interoperability can be assured for basic strings. Best, Adam -- Adam Franco Senior Software Engineer - Web Applications, Library and Information Services Middlebury College Middlebury, VT 05753 [email protected] 802.443.2244 -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
