PostAuthenticationFlows for non-SAML profiles

[Cantor, Scott]

On 8/21/15, 6:52 AM, "dev on behalf of Misagh Moayyed" <dev-bounces at shibboleth.net on behalf of mmoayyed at unicon.net> wrote:

>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"? 

URLs are not a concept users understand well, I don't know in the general case if that helps or hurts. In SAML, I think it would be fairly confusing since it wouldn't be an application URL.

OTOH, showing maybe just the virtual host might be sensible.

But we're getting into UI concepts, and we're not UI people. That's why I work on this stuff. And I'm not sure you want to complicate the OIC work with the job of trying to build a better consent UI initially. That's just my opinion.

At the moment, the general attitude seems to be that people want to start building offloaded consent systems that function entirely separately from the IdP itself, and that's probably for the best in the long run.

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

With code changes, I imagine so.

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

Also possible with code changes.

>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?

I think that model is questionable for most cases, but that was implemented, there's a property that controls it (or at least a config option).

> Or are we assuming that whatever comes out of the filter decided by the IdP deployer
>is absolutely required and I don't get a say? I ask, because I might be OK
>with releasing my userid, but don't necessarily wouldn't want to release
>my physical address. Some of these attributes may be purely optional, used
>to reconstruct my profile for the SP.

Yes, in theory. In practice, you don't have the information to make that choice in an informed way in the majority of cases, and it's complicated by a lot of other factors that aren't easy to explain in a short email.

>This bit isn't what I am going to work on anytime soon but I wonder; the
>approval page generally may explain how the service was recognized by the
>identity provider. Was it explicitly defined? Was is dynamically
>registered? Etc.

Yes, I think that makes sense. Up until now, the answer was fairly simple, but if that changes we'll have to talk about the implications of it.

-- Scott