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

John Bradley ve7jtb at ve7jtb.com
Fri Sep 2 20:03:11 UTC 2016


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> 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>https://bitbucket.org/openid/mobile/src/75eae8b8e50737059c069965c8c37e794843b510/draft-mobile-client-initiated-backchannel-authentication-01.html?at=default&fileviewer=file-view-default <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 <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.net <mailto:Openid-specs-mobile-profile at lists.openid.net>http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile <http://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/20160902/bea6838c/attachment-0001.html>


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