[Openid-specs-mobile-profile] Notes from Moderna Aug 24

Torsten Lodderstedt torsten at lodderstedt.net
Mon Sep 5 18:30:27 UTC 2016


Hi all,

I personally would prefer to have a dedicated, new endpoint for 
initializing a backchannel authentication transaction, like the OAuth 
device flow does 
(https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03). I 
consider this the cleanest and easiest way (for both OP and client 
implementors) to solve our use case. It would allow us to define 
parameters and processing rules in a way suitable for backchannel 
authentication (without imposing limitations/constraints originating 
from frontchannel authentication onto implementors).

I see the following properties of the backchannel authentication endpoint:
- HTTP method POST (only), parameters are sent in the request body
- supports client authentication (which the authz endpoint does not!) 
using client secret or JWT assertions
- utilizes existing OAuth/OIDC authorization/authentication requests 
parameters as needed, such as "scope" (but not "redirect_uri" or 
"response type")
- adds further parameters needed for backchannel authentication, such as 
"callback" or "client_notification_endpoint"
- returns auth_req_id

If we want to offer pull style processing, we could (again) follow the 
pattern proposed by the OAuth device flow and introduce a new grant type 
to the tokens endpoint for that purpose (e.g. 
"urn:openid:params:modrna:grant-type:backchannel_request"). The client 
would use this grant type along with the "auth_req_id" to query the 
results of the authentication transaction.

best regards,
Torsten.

Am 02.09.2016 um 22:03 schrieb John Bradley:
> I would base it on the RFC 7523 Authorization grant.  Using a self 
> signed Connect Request Object as the grant request.
>
> The IdP performs the out of band consent to approve the grant request.
>
> If the request is signed the RP could specify any URI it likes as a 
> post back location if you are not polling or blocking.
>
> I think this method may allso would allow for the the collection of 
> consent for transactions.
>
> I would prefer not to wind up with two separate extensions for 
> backchannel authentication (Really consent to login as it is not 
> authenticating the front channel) and consent for transactions.
>
> John B.
>> On Sep 2, 2016, at 4:33 PM, GONZALO FERNANDEZ RODRIGUEZ 
>> <gonzalo.fernandezrodriguez at telefonica.com 
>> <mailto:gonzalo.fernandezrodriguez at telefonica.com>> wrote:
>>
>> Hi again John,
>>
>> Is true the the RO credentials flow authenticate the user, but in 
>> this case the RP knows the user credentials (user/password) and it is 
>> not your case, we only knows the MSISDN and we need somehow to 
>> specify an ac_value to authenticate the user, we would also need to 
>> extend it.
>>
>> If I understand well, what you propose is not sending the parameters 
>> in the POST’s body in clear but send a GET with a unique parameter 
>> that is a signed JWT, it could be send to the Token endpoint or to 
>> another endpoint. Let’s say we use the Token endpoint, whenever a 
>> request is received is should….
>>
>>   * Checks the sign
>>   * generates the auth_req_id and
>>   * sends a response to the RP with the auth_req_id to allow the RP
>>     polling for the authentication response
>>   * select the authenticator to authenticate the user, generate
>>     tokens and send them as the poll response…..
>>
>>
>> P.S: is there any place where the attacks to the redirect_ui with 
>> parameters are documented?
>>
>> Best,
>> Gonza.
>>
>> From: John Bradley
>> Date: Friday 2 September 2016 at 19:53
>> To: Gonzalo Fernández
>> Cc: Torsten Lodderstedt, Openid-specs-mobile-profile
>> Subject: Re: [Openid-specs-mobile-profile] Notes from Moderna Aug 24
>>
>> The token endpoint is used to authenticate the user in several flows.
>>
>> Most notably the RO Credentials flow that is unfortunately widely used.
>>
>> I personally still think that this use case is much closer to the JWT 
>> assertion flow that uses the token endpoint and is used by many API 
>> providers like Google.
>>
>> In that case the client would create a signed JWT Connect request 
>> object, and send that to the token endpoint.   It could then wait for 
>> a reply or get a response and poll.
>>
>> We did discuss that option at the last face to face meeting.
>>
>> To your question yes we could create a new response mode like 
>> “direct" that would return the response in the body like we do from 
>> the token endpoint for responses.
>>
>> I do think that eliminating the registered redirect forces us to 
>> consider signed requests, so that we are not creating new security 
>> issues.
>>
>> It is the openID core spec that requires exact redirect URI matching. 
>> Anything else is a violation of the spec.
>>
>> The OAuth allows query parameters to be excluded from the match for 
>> the code flow.
>>
>> There have been some large number of attacks that take advantage of 
>> pattern matching.
>> The OAuth WG is likely going to recommend that RP create a IdP 
>> specific redirect URI and that the IDP must do exact matching on it.
>>
>> This was one of the outcomes of the OAuth security conference in July.
>>
>> John B.
>>
>>> On Sep 2, 2016, at 2:25 PM, GONZALO FERNANDEZ RODRIGUEZ 
>>> <gonzalo.fernandezrodriguez at telefonica.com 
>>> <mailto:gonzalo.fernandezrodriguez at telefonica.com>> wrote:
>>>
>>> Hi Torsten,
>>>
>>> I get you, however I don’t see such problem. It is true that the 
>>> current flows are based on redirections, but it doesn’t mean that is 
>>> necessary to have another different endpoint. What is the reason? Is 
>>> it some consistency in the design?
>>>
>>> For me the endpoint is only an entry point and it should have a 
>>> decoupled implementation depending on the flow to follow. If you 
>>> consider the semantic is more clear for the RP to use the endpoint 
>>> authorise instead of using the token endpoint, follow your same 
>>> argument, the token endpoint has not been designed to authenticate 
>>> the user, I don’t see it as candidate. I don’t mine to use another 
>>> different endpoint if we consider that is a better design.
>>>
>>> Best,
>>> Gonza.
>>>
>>> From: Torsten Lodderstedt
>>> Date: Friday 2 September 2016 at 18:15
>>> To: Gonzalo Fernández, John Bradley, Openid-specs-mobile-profile
>>> Subject: Re: [Openid-specs-mobile-profile] Notes from Moderna Aug 24
>>>
>>> Hi Gonzalo,
>>>
>>> I'm a bit confused about the discussion about response mode vs 
>>> response type vs scope because I understand why the client is 
>>> supposed to send the requests to the authorization endpoint. This 
>>> endpoint is explicitely designed for redirect-based frontchannel 
>>> flow, the exact opposite from what we are talking about in the 
>>> context of backchannel authentication. The current proposal also 
>>> does not comply with the current authz response.
>>>
>>> I think it would be a better solution to either send the first 
>>> request to the tokens endpoint or (even better) to use a distinct 
>>> (new) endpoint to initialize the process.
>>>
>>> best regards,
>>> Torsten.
>>>
>>> Am 02.09.2016 um 15:35 schrieb GONZALO FERNANDEZ RODRIGUEZ:
>>>> Hi John,
>>>>
>>>> First of all many thanks for the minutes.
>>>>
>>>> The las Wednesday we were talking about this draft in the GSMA 
>>>> meeting with operators and Mickäel Vasselet from Orange suggested 
>>>> to use the response_mode instead of the scope value openidserver 
>>>> for signalling the flow. I read the spec and it says
>>>>
>>>> response_mode
>>>>     OPTIONAL. Informs the Authorization Server of the mechanism to
>>>>     be used for returning parameters from the Authorization
>>>>     Endpoint. This use of this parameter is NOT RECOMMENDED when
>>>>     the Response Mode that would be requested is the default mode
>>>>     specified for the Response Type. 
>>>>
>>>>
>>>> In our last call, John suggested to use a new response_type instead 
>>>> of a scope value, so I think we can define a default mode for the 
>>>> new response_type that returns id_token and access_token. Is this 
>>>> ok?, Anyone would like suggesting a name for the new response_type?
>>>>
>>>>
>>>> Best,
>>>> Gonza.
>>>>
>>>> From: Openid-specs-mobile-profile 
>>>> <openid-specs-mobile-profile-bounces at lists.openid.net 
>>>> <mailto:openid-specs-mobile-profile-bounces at lists.openid.net>> on 
>>>> behalf of John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>>
>>>> Date: miércoles, 24 de agosto de 2016, 19:03
>>>> To: Openid-specs-mobile-profile 
>>>> <openid-specs-mobile-profile at lists.openid.net 
>>>> <mailto:openid-specs-mobile-profile at lists.openid.net>>
>>>> Subject: [Openid-specs-mobile-profile] Notes from Moderna Aug 24
>>>>
>>>>
>>>>
>>>> Bjorn
>>>> Gonzalo
>>>> Nat
>>>> James
>>>> Shiva
>>>> Mohajeri
>>>> John
>>>>
>>>>
>>>> September WS we need agenda and info to book hotels.
>>>>
>>>> Gonzalo Back channel draft.
>>>> New version uploaded last week.
>>>> https://bitbucket.org/openid/mobile/src/75eae8b8e50737059c069965c8c37e794843b510/draft-mobile-client-initiated-backchannel-authentication-01.html?at=default&fileviewer=file-view-default 
>>>>
>>>>
>>>> Need discussion on the auth_req_id  vs dymamic redirect_uri for 
>>>> post response
>>>>
>>>> Need discussion on defining a new response_type vs a scope for 
>>>> signalling the flow.
>>>>
>>>> Long discussion on poling response vs Post push.
>>>>
>>>> We discussed the similarity with the device flow that uses long 
>>>> polling and may be updated to support out of band push for 
>>>> consent/authentication rather as well as the current type the URI 
>>>> method.
>>>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow
>>>>
>>>> John observed that polling may be easier logic for some RP to 
>>>> implement, and can work with non server devices.
>>>> Posting back to the client also introduces new security 
>>>> considerations, if mutual TLS is not used.
>>>> The whole response may need to be signed eg include the auth_req_id 
>>>> inside the id_token.
>>>> Connect is defining Session ID  “sid” as part of logout, that might 
>>>> be something we could use instead of auth_req_id to correlate in 
>>>> the POST case, as it will be a id_token claim.
>>>>
>>>> Shiva is going to get feedback from operators on the backchannel 
>>>> draft and circulate to the WG.
>>>>
>>>> John B.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su 
>>>> destinatario, puede contener información privilegiada o 
>>>> confidencial y es para uso exclusivo de la persona o entidad de 
>>>> destino. Si no es usted. el destinatario indicado, queda notificado 
>>>> de que la lectura, utilización, divulgación y/o copia sin 
>>>> autorización puede estar prohibida en virtud de la legislación 
>>>> vigente. Si ha recibido este mensaje por error, le rogamos que nos 
>>>> lo comunique inmediatamente por esta misma vía y proceda a su 
>>>> destrucción.
>>>>
>>>> The information contained in this transmission is privileged and 
>>>> confidential information intended only for the use of the 
>>>> individual or entity named above. If the reader of this message is 
>>>> not the intended recipient, you are hereby notified that any 
>>>> dissemination, distribution or copying of this communication is 
>>>> strictly prohibited. If you have received this transmission in 
>>>> error, do not read it. Please immediately reply to the sender that 
>>>> you have received this communication in error and then delete it.
>>>>
>>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
>>>> destinatário, pode conter informação privilegiada ou confidencial e 
>>>> é para uso exclusivo da pessoa ou entidade de destino. Se não é 
>>>> vossa senhoria o destinatário indicado, fica notificado de que a 
>>>> leitura, utilização, divulgação e/ou cópia sem autorização pode 
>>>> estar proibida em virtude da legislação vigente. Se recebeu esta 
>>>> mensagem por erro, rogamos-lhe que nos o comunique imediatamente 
>>>> por esta mesma via e proceda a sua destruição
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-mobile-profile mailing list
>>>> Openid-specs-mobile-profile at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su 
>>> destinatario, puede contener información privilegiada o confidencial 
>>> y es para uso exclusivo de la persona o entidad de destino. Si no es 
>>> usted. el destinatario indicado, queda notificado de que la lectura, 
>>> utilización, divulgación y/o copia sin autorización puede estar 
>>> prohibida en virtud de la legislación vigente. Si ha recibido este 
>>> mensaje por error, le rogamos que nos lo comunique inmediatamente 
>>> por esta misma vía y proceda a su destrucción.
>>>
>>> The information contained in this transmission is privileged and 
>>> confidential information intended only for the use of the individual 
>>> or entity named above. If the reader of this message is not the 
>>> intended recipient, you are hereby notified that any dissemination, 
>>> distribution or copying of this communication is strictly 
>>> prohibited. If you have received this transmission in error, do not 
>>> read it. Please immediately reply to the sender that you have 
>>> received this communication in error and then delete it.
>>>
>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
>>> destinatário, pode conter informação privilegiada ou confidencial e 
>>> é para uso exclusivo da pessoa ou entidade de destino. Se não é 
>>> vossa senhoria o destinatário indicado, fica notificado de que a 
>>> leitura, utilização, divulgação e/ou cópia sem autorização pode 
>>> estar proibida em virtude da legislação vigente. Se recebeu esta 
>>> mensagem por erro, rogamos-lhe que nos o comunique imediatamente por 
>>> esta mesma via e proceda a sua destruição
>>
>>
>> ------------------------------------------------------------------------
>>
>> Este mensaje y sus adjuntos se dirigen exclusivamente a su 
>> destinatario, puede contener información privilegiada o confidencial 
>> y es para uso exclusivo de la persona o entidad de destino. Si no es 
>> usted. el destinatario indicado, queda notificado de que la lectura, 
>> utilización, divulgación y/o copia sin autorización puede estar 
>> prohibida en virtud de la legislación vigente. Si ha recibido este 
>> mensaje por error, le rogamos que nos lo comunique inmediatamente por 
>> esta misma vía y proceda a su destrucción.
>>
>> The information contained in this transmission is privileged and 
>> confidential information intended only for the use of the individual 
>> or entity named above. If the reader of this message is not the 
>> intended recipient, you are hereby notified that any dissemination, 
>> distribution or copying of this communication is strictly prohibited. 
>> If you have received this transmission in error, do not read it. 
>> Please immediately reply to the sender that you have received this 
>> communication in error and then delete it.
>>
>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
>> destinatário, pode conter informação privilegiada ou confidencial e é 
>> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa 
>> senhoria o destinatário indicado, fica notificado de que a leitura, 
>> utilização, divulgação e/ou cópia sem autorização pode estar proibida 
>> em virtude da legislação vigente. Se recebeu esta mensagem por erro, 
>> rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
>> proceda a sua destruição
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160905/fde61273/attachment-0001.html>


More information about the Openid-specs-mobile-profile mailing list