I almost wrote about that natural progression in my original post: certainly for consumer/user-driven use cases, human-initiated always precedes and authorizes app-to-app, and app-to-app precedes and authorizes app-to-human.

You’re right that OAuth is generally used during an ongoing human-initiated session, but I think it need not, and certainly ID-WSF doesn’t assume it. Maybe it would be useful to add the “session” semantic explicitly to this framework (such as it is), to make the set of use cases more clear and maybe even inform IGF (or IGF++) work.

Wrt Eric’s point, users are vulnerable to phishing not because they can receive unsolicited app-initiated messages, but because they bear the burden of authenticating the sender. The user’s IDP is better qualified to do this on their behalf.

Wrt OAuth, where Ive seen it used so far, the pattern would seem to be still human-initiated, its just the message flow is app-to-app. I’ve seen Oauth used for the initial bulk transfer of attributes, but not subsequent ‘syncing’. I may well just not be looking at the right places.

I love the point you make about today’s (forced) binary decision making for users – thereby allowing for no shades of service. It does suggest to me that apps, in addition to expressing what identity they need, should be also able to indicate the implications of their not receiving it. I dont think IGF covers this ….

paul

p.s. I love Interaction Service, I do. It’s just that we’re at different places right now

Eric– Excellent point. We already have lots of apps reach out to us in email, and of course we risk being phished this way. Mutual authentication is especially important if we’re being asked to take significant action, and there are ways to have the app authenticate to us, such showing that it knows a shared secret.

One-time passwords sent through SMS are already used in the human-to-app pattern; I can see SMS being used pretty heavily in the reverse pattern, at least to kick off an interaction where you’re fully paying attention. E.g., for complex actions such as the longitudinal study scenario, it might ask you to call a number where you punch in answers to a list of robo-questions.

One of the reasons I think we need to take the app-to-human pattern seriously is that it turns our decision-making — consent or not? share data or not? — into something more meaningful than the pro forma “click the I Agree button” consent we’re made to do all the time. If you set up a policy to have an app ask you for a decision at a critical moment, its logic must be prepared to do some interesting X if Yes and do some other interesting Y if No. Today, X=Give Service and Y=Refuse Service.