PostAuthenticationFlows for non-SAML profiles

[Rod Widdowson]

> 
> The attribute-release screen shows me a set of attributes that are going
> to be released to service. It doesn't list which "service". Cognitively, I
> know what service that is but it would be better if the screen actually
> listed that. Possible?

Absolutely :

https://wiki.shibboleth.net/confluence/display/IDP30/VelocityProperties#Velo
cityProperties-Propertiesusedduringattributerelease

It does seem to make sense that the SP be named in the default page.  Can
you enter a RFI?
 
> Moreover, does it make sense for the Idp to actually tell the user where
> they would be going if they press Accept/Authorize? Show a URL on the page
> that says "This is where you'll end up if you press X"?

Again you can customize this.  Not being a UI person I have no idea whether
this is a good idea.

> Is there a way for the same screen to show how many times the service has
> been approved, previously?

I'll let Tom answer that

> Can the same screen remember my choice for a configurable period of time?

And that 

https://wiki.shibboleth.net/confluence/display/IDP30/ConsentConfiguration#Co
nsentConfiguration-StorageRecordLifetime

> It seems like the attribute release function is all or nothing. You either
> accept to release everything or you do not. Is there ever a need to have
> the user selectively decide which attributes may be release [Lots of good
stuff snipped]

In V3 the aim was to get the framework in place to allow others to play
around with these sorts of ideas (people *love* playing with UIs, or at
least suggesting that others do).  It's all out there for people to look at
now.

I am *NOT* a UI person and I am not speaking for the project, but my main
concern with this sort of stuff is that it becomes improbably difficult for
an end user to understand what will happen.  I decide to not release an
attribute which an SP requires so the response goes to the SP which then
fails (in an odd manner).  If I say No to everything then it's obvious (I
claim), but how do you explain that for one SP refusing to release the email
address just ends up in a degradation of service (you have to enter the
address by hand if you want), but in others that the service will flat out
stop working (in an odd manner).

There have been various attempts to provide some sort of management
framework for this bit to my mind they tend to purely demonstrate that it is
really hard if not impossible to get right and that an O(n^2) problem needs
careful control.

I'm really hoping (and indeed expecting) that we may seem some active
research on the back on V3 to play with these possibilities and see what
happens.