[Openid-specs-mobile-profile] Mobile Profile parameters

Nat Sakimura sakimura at gmail.com
Wed Apr 29 14:01:08 UTC 2015 

I-D instead of RFC, I suppose ;-) but it is a good work.

> I did a RFC on how a client can use state
> that might be a useful reference.
> https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state

+1 for Requiring PKCE.

2015年4月29日(水) 3:16 John Bradley <ve7jtb at ve7jtb.com>:

> PKCE
> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/
>
> We are in the last stages of review before becoming a RFC.
>
>
> On Apr 28, 2015, at 2:49 PM, GONZALO FERNANDEZ RODRIGUEZ <
> gonzalo.fernandezrodriguez at telefonica.com> wrote:
>
>  Thanks again John,
>
>  I am going to check the RFC of the jwt encoded state. By the moment my
> understanding is that state shouldn’t be a mandatory parameter in the
> Mobile OIDC profile.
>
>  BTW what is PKCE?
>
>  Best,
> Gonza.
>
>   From: John Bradley <ve7jtb at ve7jtb.com>
> Date: Tuesday 28 April 2015 18:17
> To: Gonzalo Fernández <gonzalo.fernandezrodriguez at telefonica.com>
> Cc: "openid-specs-mobile-profile at lists.openid.net" <
> openid-specs-mobile-profile at lists.openid.net>
> Subject: Re: [Openid-specs-mobile-profile] Mobile Profile parameters
>
>   The AS MUST support state.
>
>  It is recommended that the client send it to protect against XSRF.
> Requiring the client to send it is a bit extreme as the the value is opaque
> to the AS.
> State  makes little sense for native apps, Especially if they are using
> the code flow and PKCE (formerly SPOP)
>
>  All you are really doing is forcing some people to include a parameter
> that they will ignore by making it required for the client to send it.
>
>  One thing that you should do is require all AS to support PKCE and all
> public clients to use it.
> That both provides XRSF protection and protection from having the code
> intercepted in the response.
>
>  Besides XSRF protection state provides a way for the client to track
> state information about the request.
> The problem is that clients try to tack on additional query parameters for
> themselves in the redirect_uri, and that can be a security problem.
>
>  In Connect we require exact matching of the redirect_uri as a MUST for
> the AS that largely forces any client wanting to maintain some sort of
> state around the request to send it as the value of the state parameter.
>
>  I did a RFC on how a client can use state that might be a useful
> reference.
> https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state
>
>  John B.
>
>  On Apr 28, 2015, at 11:18 AM, GONZALO FERNANDEZ RODRIGUEZ <
> gonzalo.fernandezrodriguez at telefonica.com> wrote:
>
>   Hi guys,
>
>  Just a quick question. Do we have a final decision about to turn the
> state parameter into mandatory for the Mobile Profile?
>
>  The GSMA document "Mobile OIDC Profile" will have "nonce" and
> "acr_values" parameter as "Recommended" in the next version, but they are
> waiting for a response from this WG and I don't remember if there is an
> agreement about how should be the status of the "state" parameter:
> Recommended or Mandatory.
>
>  Best,
> Gonza.
>
>   De: John Bradley <ve7jtb at ve7jtb.com>
> Fecha: martes 7 de abril de 2015 16:11
> Para: Gonzalo Fernandez Rodriguez <
> gonzalo.fernandezrodriguez at telefonica.com>
> CC: "openid-specs-mobile-profile at lists.openid.net" <
> openid-specs-mobile-profile at lists.openid.net>
> Asunto: Re: [Openid-specs-mobile-profile] Mobile Profile parameters
>
>   max-age is something we do need to talk about.
>
>  There is a question of what it means in the mobile connect case where
> the user is logging in from a desktop/laptop.
>
>  If the user has a cookie with the IdP in the browser because they used
> mobile connect to log-into site a 8h ago from a home computer.
> The same user 7h later goes to site B on a different device and performs
> mobile connect login from there office to a site with max-age = 1h.
>
>  Now the persons child goes to the first computer and loges into site C
> still with a valid session cookie and the max-age is 2h.
>
>  The person last authenticated interactively with mobile connect 1h ago
> is that what is reported to site C, or is it 8h that is reported?
>
>  None of the authentication specs really consider the sort of out of band
> authentication across multiple devices that we are proposing.
>
>  This is something that the mobile profile will need to expand on so that
> IdP are consistent on how they treat that value.
>
>  The other thing to consider is what constitutes interactive login.
> That may require a OK confirmation if the login device is separate from
> the authentication device, or it might require a pin if it is the same
> device.
>
>  However if you know the device has a screen lock then perhaps ok may not
> be needed if the cookie is strongly bound to the device as it would be a
> security no op that just annoys the user for no reason.
>
>  Ther are a number of issues that will need to be considered.
>
>  I don't know that I would even recommend sending auth time, by the
> client.   In principal the AS/MNO should be best positioned to determine if
> the risk score requires additional factors such as re-prompting.
>
>  John B.
>
>
>   On Apr 7, 2015, at 6:49 AM, GONZALO FERNANDEZ RODRIGUEZ <
> gonzalo.fernandezrodriguez at telefonica.com> wrote:
>
>  Hi John,
>
>  Very interesting your arguments, I fully agree.
>
>  I had a mistake with prompt and max_age because they change from
> Optional to Recommended, sorry!
>
>  Best,
> Gonza.
>
>   De: John Bradley <ve7jtb at ve7jtb.com>
> Fecha: martes 7 de abril de 2015 15:32
> Para: Gonzalo Fernandez Rodriguez <
> gonzalo.fernandezrodriguez at telefonica.com>
> CC: "openid-specs-mobile-profile at lists.openid.net" <
> openid-specs-mobile-profile at lists.openid.net>
> Asunto: Re: [Openid-specs-mobile-profile] Mobile Profile parameters
>
>   nonce and state are opaque to the AS and required for the AS to support
> now.
>
>  Forcing a client to send them may not achieve anything if the client
> sticks some static value in them to fulfill the spec.
> Teaching clients to use them properly to protect themselves is more
> important.
>
>  We debated making nonce required for code, but decided that there were
> sufficient protections by validating the redirect_uri at the token endpoint.
>
>  max_age is probably a bad thing to force clients to send.  It will end
> in tears because clients will not understand what it means and cause a bad
> user experience.
>
>  sending prompt every-time will also have bad user experience
> consequences,  mostly you don't want to send it unless you really want
> something other than the default of prompting the user only if they need to
> re-auth, or not prompt,
> and return an error to the client if they need to re-auth (this allows a
> background check in a iframe).
>
>  Forcing the client to request a acr if it is willing to take anything
> also seems a bit misguided.
>
>  So I would say that who ever came up with that has a limited
> understanding of Connect.
>
>  John B.
>
> On Apr 7, 2015, at 1:59 AM, GONZALO FERNANDEZ RODRIGUEZ <
> gonzalo.fernandezrodriguez at telefonica.com> wrote:
>
>
>   Hi Guys,
>
>  I have been reviewing the Mobile Connect Profile doc released by the
> GSMA. There are some parameters in the authentication request, id_token and
> userinfo that have changed their use from optional to recommend or
> mandatory (These cases are showed in green). I don't think it is a problem
> to turn an optional parameter into mandatory in responses (id_token or
> userinfo), but I would like to highlight the cases where the spec says that
> the parameters are optional in the authentication request and the Mobile
> Profile says that they are mandatory, because I think they break the
> backward compatibility of the OIDC servers unless we can to differentiate
> the mobile profile requests from the other requests.
>
>  PARAMETER SPEC MOBILE PROFILE
> -------------------        ---------------------
>  ------------------------
> state RecommendedMandatory
>   nonce Recommended Mandatory
>     prompt Recommended Mandatory
>    max_age Recommended Mandatory
>    acr_values Recommended Mandatory
>
>   I understand that state and nonce offer and added value from the point
> of view of security, however I don't see the benefit of the acr_values as
> mandatory parameter.
>
>
>  Best,
> Gonza.
>
> ------------------------------
>
> 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
>
>
>
> ------------------------------
>
> 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
>
>
>
> ------------------------------
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20150429/8eda5adf/attachment-0001.html>

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