Adam, Thanks, this is great feedback. I agree that some guidance would be helpful. I've add your comments to the current working draft. And expect we'll address this issue.
I think it's helpful to keep in mind that the goal of the current protocol rev and the patch for CAS4 is simply to codify current practice around adding attributes to the CAS validate response. That essentially means optionally adding a <cas:attributes> block that supports <name>value</name> formatting and leaves it up to the client as to how to interpret it. In terms of more complex data types, encoding, and what not. I think we'll have a chance to address that in the next revision when LOA gets another look. Best, Bill On Mon, Apr 8, 2013 at 4:28 PM, Adam Franco <[email protected]> wrote: > 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 -- 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
