[Openid-specs-native-apps] Consent models (re: Minutes - March 19)

[Mike Varley]

Hi all, sorry to have missed the meeting. I noticed that the consent question came up, and I'd like to share some of the challenges I've come across, just for consideration (again, apologies if this was covered on the call). In general, the experience has been that the various subtleties and nuances of consent can vastly complicate the model and user experience.  

If you have a model of 'implied consent' (i.e., authentication at the AS authorizes the App for whatever it needs):
- may be suitable for tightly controlled Enterprise deployments
- provides a simplified user experience
- puts the user at risk of leaking data/PII
- "all-or-nothing" consent may be a barrier to entry for users

If you have a JIT consent model:
- more suitable for 'public' or general federations of Apps and Resources
- more burden on the user, as they have to authorize against each RS for each App
- usually involves more network round-trips, which on a mobile device can impose a noticeable  delay
- RSs have to choose an entity to trust that consent has been collected:
-- Trust the AS has presented the user with the right scopes/terms of service
    (how does the AS keep these in sync with the RS policy? Is there anything in the 'scopes' themselves that leak PII? )
-- Trust the TA that it has collected consent directly from the RS before issuing tickets to the Apps 
    (usually means the RS must return a 'session scope auth token' to the TA that gets embedded in the Auth Token - and AppInfo endpoint must point TA to RS consent endpoints)
-- Trust only 'yourself' (RS) meaning each App will have to present the authentication token with a _desired_ scope, and the RS must be able to collect consent itself.
    (has App UI implications, as the App must now be able to render the RS consent screen)


User consent is a very important part of this kind of system, to be sure - but attempting to solve the "entire problem for all ecosystems" will probably only lead to pain and sadness ;) So I am assuming the NAPPS spec will only try to define 'consent extension points', where any particular ecosystem can expand on to fit their own consent / privacy model.

I hope this was useful.

Thanks, 

MV 






On Mar 20, 2014, at 8:38 AM, Paul Madsen <paul.madsen at gmail.com> wrote:

> Attending
> 
> Paul
> John
> Chuck
> Ashish
> 
> 1) Ashish reported back on the RSA F2F
> 
> Attending were Mike & Caleb from MSFT, some MobileIron & Airwatch folks, somebody from OneLogin
> 
> Ashish asked for people's assessment of group value. Group agreed there was a need and worthwhile 
> 
> Microsoft challenging the value - claiming that something like this would be eventually be addressed by the OS vendors. Group feels the interapp piece (that the OS vendors will address) is just half the problem, the other half is the on-the-wire protocol between TA & AS 
> 
> In offline conversations with John, MSFT reps agreed that there was value in defining the on-the-wire protocol. 
> 
> Perhaps we can clarify that we don't intend to mandate a particular interapp protocol
> 
> Ashish adds there was agreement that we need more ISVs participating , action item was to reach out to contacts at the SaaS. 
> 
> John indicates he talked to Layer7 at MWC and that they feel they have comparable functionality
> 
> 2) Discussion of the different models for token-chaining, and how/where the complexity of dealing with token chaining sits - does the TA deal with the exchange, or does the app deal with the exchange
> 
> John points out the implications of the trust models, and who needs to know what? 
> 
> AI - John will put together a summary of the different models and the pros/cons of each
> 
> Ashish asked about a model where the trust and token exchange happens at the AS level
> 
> Permuations appear to be 
> 
> - TA asks downstream AS for AT
> - Downstream app asks downstream AS for AT
> - Upstream AS asks downstream AS for AT
> 
> Implications for consent gathering
> 
> 2) Discussion about the use case of bridging from the TA into web app SSO
> 
> Everybody has a different way to do this
> 
> Ashish points out an issue about how to get session info into a web clip....
> 
> Different UI implications/models
> 
> AI - Paul will start a thread on the use case on the NAPPS list
> 
> 3) Chuck remains concerned about the consent model - believes the spec as it is is primarily focused on authentication, and not about authz.
> 
> Different consent models differ on where the consent happens, at the TA or at the AS
> 
> John points out that this relates to the lack of the 'pre-authenticated authz request' 
> 
> Chuck wants their server involved in collecting consent, and wants that to happen JIT and not a priori 
> 
> John points out that this ties in with the bootstrap to browser app piece
> 
> AI - Chuck will summarize his thoughts on consent (where & when) on the list
> 
> Meeting closed
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Openid-specs-native-apps mailing list
> Openid-specs-native-apps at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps