CAS Protocol Milestone

[Cantor, Scott]

On 8/14/14, 2:36 PM, "Marvin Addison" <marvin.addison at gmail.com> wrote:

>- User consent attribute release (future)

I still need to review Tom's initial notes on the consent work, it might
be a good idea to take a look at that with some CAS eyes. Obviously the
underlying material this is operating on is internal to the IdP and
protocol neutral, but there may be issues with the kind of information
available (or not) to the UI about the request.

>It's hard to overstate the value of the attribute engine integration:
>id mappings, complex value transforms, and variable encodings. These
>use cases have come up repeatedly in the CAS community over the years.

Yeah, obviously we think it's pretty insane for people to go redo all that
work.

>I would like to start the discussion of integrating this work into the
>IdP codebase so it ships with v3 (ideally by beta). I hope the value
>proposition is clear, but I'm happy to field questions if you need
>more information.

For me there are two main considerations:

- integration/alignment with the relying-party configuration mechanism
- the long term maintenance question

The former I mentioned earlier. I don't necessarily intend to say that I
think use of metadata is a precondition, it's not. But if there's no
metadata, there's either no RP identity (the Anonymous RP bucket), or we
have to collapse location into identity and basically treat the return
path as an effective identity to trigger off of.

My personal feeling is that we either profile and implement metadata for
this, which is quite easy, or we should treat the requests as Anonymous
(and thus subject to that policy assumption for attribute release).

The maintenance issue is I guess up for discussion. I'm assuming from the
work that you've done that you're interested in at least assisting with
support and maintenance? One of the reasons we move more slowly re:
features is that we don't add anything to core that we haven't
collectively had a hand in writing. That's why people think we're hostile
to contributions; we're not, we just don't take over large chunks of code
with no ongoing plan. We don't want to have to drop support later for
something because we've lost the resources to maintain it.

The rest of the issues are just the minor things like adding in the
features that aren't done yet for SAML, like the audit logging I'm working
on now.

But if the maintenance story makes sense and if the alignment
configuration/policy wise is sound, I don't have an objection as long as
it doesn't impact our schedule. It could also just be a quick follow on
3.1 addition anyway.

-- Scott