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

Fri Sep 2 17:26:57 UTC 2016

I meant "I don't understand why the client is supposed to send the requests to the authorization endpoint."

Sent by MailWise – See your emails as clean, short chats.

-------- Ursprüngliche Nachricht --------
Von: Torsten Lodderstedt <torsten at lodderstedt.net>
Gesendet: Friday, September 2, 2016 06:15 PM
An: GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com>,John Bradley <ve7jtb at ve7jtb.com>,Openid-specs-mobile-profile <openid-specs-mobile-profile at lists.openid.net>
Betreff: 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.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>
>
>_______________________________________________
>Openid-specs-mobile-profile mailing list
>Openid-specs-mobile-profile at lists.openid.net
>http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20160902/d45dc63e/attachment.html>