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

Paul Madsen paul.madsen at gmail.com
Tue Apr 8 20:14:59 UTC 2014

for comparison, John's proposed model


On 4/8/14, 3:49 PM, John Bradley wrote:
> I was thinking of using the response_type=none for the outh flow to 
> AS2 simply to collect consent.
> The JWT or SAML assertion flow would be used to get the access token 
> from AS2.   The downside is that AS2 needs to support the assertion 
> flow but the upside is that AS1 has the ability to revoke access 
> without going thorough web redirects each time the AT needs to be 
> refreshed.
> On Apr 8, 2014, at 1:35 PM, Paul Madsen <paul.madsen at gmail.com 
> <mailto:paul.madsen at gmail.com>> wrote:
>> I think this wsd describes John's model
>> Question - in the step that John refers to as 'trigger the IdP 
>> initiated login via Connect or SAML' - what support is there for an 
>> authenticated authz request?
>> Distinct from how the browser gets sent to AS2 is what AS2 returns - 
>> in this case a code, and the TA exchanges that code for the desired 
>> AT ( to be handed to the native app)
>> John was advocating a different model
>> paul
>> On 4/8/14, 2:46 PM, John Bradley wrote:
>>> For bootstrapping a web session in SAML as an example you could 
>>> directly create a IdP initiated login URI + post body and have the 
>>> browser send that to the third party AS directly.
>>> I think that is more problematic from a security perspective as 
>>> there is no way for the home AS to say compare the ip address of the 
>>> browser with the ip address of the TA or make use of other 
>>> authentication factors.
>>> Logically I prefer to have the TA bootstrap the browser to itself 
>>> and from there trigger the IdP initiated login via Connect or SAML. 
>>>   That is the only way you can do a IdP initiated login with 
>>> connect, otherwise the user needs to authenticate to there home AS 
>>> in the browser somewhat defeating the point.
>>> On Apr 8, 2014, at 12:36 PM, Paul Madsen <paul.madsen at gmail.com 
>>> <mailto:paul.madsen at gmail.com>> wrote:
>>>> hi Mike, inline
>>>> paul
>>>> On 4/7/14, 9:19 AM, Mike Varley wrote:
>>>>> A couple comments/questions:
>>>>> 1) what is the 'API' endpoint the bootstrap URL request is going 
>>>>> to? Is this the RS?
>>>> would be the AppInfo endpoint (hosted by AS1) that the NAPPS spec 
>>>> describes
>>>> To obtain application metadata information, the /TA/ MAY make a GET 
>>>> or POST request to the AppInfo Endpoint.
>>>>> 2) Seems like a lot of round-trips. On mobile, performance will suffer
>>>> if the round trips are performed only for gathering consent ....
>>>>> 3) how does consent from the browser result in an AT to the App?
>>>> John proposed a model where
>>>> 1) the TA is delivered an id_token targeted at AS2
>>>> 2) the user agent is sent to AS2 for consent
>>>> 3) once consent is obtained, the TA exchanges the id_token for an AT
>>>> 4) TA hands AT to 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

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

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