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

Mike Varley mike.varley at securekey.com
Mon Apr 7 13:19:09 UTC 2014


A couple comments/questions:
1) what is the 'API' endpoint the bootstrap URL request is going to? Is this the RS?
2) Seems like a lot of round-trips. On mobile, performance will suffer
3) how does consent from the browser result in an AT to the App?

MV

On Apr 4, 2014, at 5:53 PM, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:

If the target of the SAML IdP initiated login is the OAuth authorization Uri we shouldn't need extra attributes in the SAML assertion.

Sent from my iPhone

On Apr 4, 2014, at 3:16 PM, Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>> wrote:

I dont think we should preclude IdP-init SAML into the AS2 consent page - for those SaaS currently set up as SAML SPs & OAuth AS

implying us defining a scope param on the SAML Response?


On 4/4/14, 2:16 PM, John Bradley wrote:
Yes.

There are two options I can think of for the last step of AS2 collecting consent.

The request can have a response_type of code and the TA gets back a code that it can use to get a AT from the AS2 token endpoint.

The other would be to make the call to AS2 with a response-type of "none" just to collect consent, getting back nothing.
The TA would then use the JWT assertion flow to exchange a JWT for the access token.

I think the second option is more secure and allows a JWT issued by AS1 to be used instead of a refresh token issued by AS2.  The advantage is that AS1 has the ability to revoke access to the resource without needing a separate API to AS2.

John B.


On Apr 4, 2014, at 2:00 PM, Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>> wrote:

John, something like

http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgYnJvd3NlcgoACAxUQQACDUFTMQACDlBJABEPMgoKClRBLT5BUzE6IGdldCB1c2VyIGF1dGhlbnRpY2F0ZWQKQVMxLT5UQTogUlQsQVQAKQdQSQArBUJvb3RzdHJhcChBVCkKQVBJACQGYm9vABEFVVJMAFoGAIEmBwAVBQArBgAWBQCBPQcAeQcADg4AcgUALwlyZWRpcmVjdCB0byBBUzIoaWRfdG9rZW4sc2NvcGUpAD4NMjoAgT0FenJlcXVlc3QAGhJub3RlIG92ZXIgACgFdmFsaWRhdGUgAE0ICgpBUzIAgSoLY29uc2VudCgAZgY_CgoKCgo&s=patent


On 4/4/14, 1:42 PM, John Bradley wrote:
I was thinking of a bootstrap URL that trigged idP initiated login at AS2.  That way the bootstrap URI is essentially opaque as it is both specified and consumed by the IsP/AS of the TA.


On Apr 4, 2014, at 1:26 PM, Chuck Mortimore <cmortimore at salesforce.com<mailto:cmortimore at salesforce.com>> wrote:

Sounds similar, yes, although working out a boostrap URL across different ASs might be quite difficult in practice


On Fri, Apr 4, 2014 at 10:25 AM, Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>> wrote:
hey Chuck, you write

'If the TA were to simply use it's primary token to initialize an OAuth authorization request for the scope of the requesting native app, we could simplify this whole thing.  '

John had (in this thread) previously proposed something similar

'If we have a web app bootstrap AS1 could give a bootstrap URI to the App that would create a authenticated session at AS2 for the user to do the normal OAuth consent flow.'

I believe John's model accomplishes the same thing as your proposal, ie delivers the user's browser (in an authenticated state) to an AS where consent can be gathered - albeit perhaps with more steps

paul

On 4/2/14, 5:49 PM, Chuck Mortimore wrote:
We don't think there should at all be an "implied consent" model (i.e., authentication at the AS authorizes the App for whatever it needs).    This sound quite dangerous, and don't believe this would at all be suitable for a tightly controlled enterprise environment.    We do support models that "feel" like this, but consent really isn't implicit...It's simply isn't controlled or visilbe to the the user.   We always run the request through an authorization check, and it is not at all coupled to authentication.   Picture us checking a role on the AS.

As far JIT consent model, it's a bit harder to achieve when using the Token Endpoint, unless we explicitly specify the TA is collecting consent, what to collect, etc.  Standardizing a consent UI strikes me as very difficult.

The way we've balanced the two in our environment is to always perform consent on the authorization endpoint.   Based on the configuration of the app, we're either checking server side admin defined consent, or prompting the user.

It's possible we could continue to use this model in NAPPS - if we consider the real difficult issue for users is actually authenticating, then authorization is really not a big deal.   If the TA were to simply use it's primary token to initialize an OAuth authorization request for the scope of the requesting native app, we could simplify this whole thing.

-cmort


On Thu, Mar 20, 2014 at 1:37 PM, Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>> wrote:
exploring #5 and your scenario

something like

1) TA gets user authenticated and obtains refresh token with certain scopes
2) TA somehow knows that for a particular app, additional consent is needed, and that a 3rd party AS2 has to collect it
3) TA uses its RT to obtain an id_token targeted at 3rd party AS2
4) TA attaches id_token to authz request when browser sent to AS2
5) AS2 collects consent
6) AS2 returns code/token etc to TA

Different options for  Steps #3 & #4 exist

paul

On 3/20/14, 3:44 PM, John Bradley wrote:
Inline
On Mar 20, 2014, at 4:34 PM, Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>> wrote:

possible permutations?

Single AS
    1) consent collected at AS
    2) consent collected at TA (and reported to AS in access token request?)
For 2 some UI elements need to be delivered to the TA perhaps via AppInfo

Two ASs
    3) consent collected at AS1 (and reported to AS2 in id_token?)
If AS 2 trusts AS1to collect consent it could just list the scopes granted.
    4) consent collected at TA (and reported to AS2 in access token request?)
This perhaps works if the TA is making a authenticated request to AS2.  I think 3 or 5 is more likely.
    5) consent collected at AS2
If we have a web app bootstrap AS1 could give a bootstrap URI to the App that would create a authenticated session at AS2 for the user to do the normal OAuth consent flow.


paul

On 3/20/14, 11:02 AM, John Bradley wrote:

I think our conversation about collecting consent was mostly focused on the basic case where the AS the TA is talking to can directly mint access tokens.

We still may need to collect user consent beyond what was agreed to at initial setup of the TA.

I think you are going one step further where the first party AS collects consent on behalf of the 3rd party AS/RS and indicates that in the id_token.

The second one is harder in that the third party AS would somehow need to communicate it's scopes out of band to the 1st party AS for collection.

John B.

On Mar 20, 2014, at 11:51 AM, Mike Varley <mike.varley at securekey.com><mailto:mike.varley at securekey.com> wrote:



Yeah, probably - something like a 'consent' field in the id_token or AppInfo response that the RS can match to the scope. Just making something up on the spot (and in no way really thought through but what the heck) maybe something like:

consent: implicit      //> RS should decide if it trusts AS, or maybe query AS as to what the implied consent involves.
consent: <consent_token>   //> RS should examine token to see if it matches the scope and session the token was issued to.
consent: none         //> RS should explicitly ask for consent

Note that the RS will always have final say on whether to trust the AS/TA, and whether or not to explicitly collect further user consent.

This is just a thought, love to hear more ideas.

thanks,

MV

On Mar 20, 2014, at 10:39 AM, Paul Madsen <paul.madsen at gmail.com><mailto:paul.madsen at gmail.com> wrote:



Thanks Mike, yes Chuck raised some of the same concerns/points

What might a 'consent extension point' look like? Just suitable OPT mechanisms?

Paul

On 3/20/14, 10:32 AM, Mike Varley wrote:


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><mailto: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<mailto:Openid-specs-native-apps at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-native-apps


_______________________________________________
Openid-specs-native-apps mailing list

Openid-specs-native-apps at lists.openid.net<mailto:Openid-specs-native-apps at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-native-apps


_______________________________________________
Openid-specs-native-apps mailing list
Openid-specs-native-apps at lists.openid.net<mailto:Openid-specs-native-apps at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-native-apps





_______________________________________________
Openid-specs-native-apps mailing list
Openid-specs-native-apps at lists.openid.net<mailto:Openid-specs-native-apps at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-native-apps








_______________________________________________
Openid-specs-native-apps mailing list
Openid-specs-native-apps at lists.openid.net<mailto:Openid-specs-native-apps at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-native-apps

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140407/3900f696/attachment-0001.html>


More information about the Openid-specs-native-apps mailing list