[OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up

[William Denniss]

Thanks all who joined us in Chicago in person and remotely last month for
the discussion on the device flow. [recording here
<https://play.conf.meetecho.com/Playout/?session=IETF98-OAUTH-20170327-1710>,
presentation starts at about 7min in].

The most contentious topic was addition of the user_code URI param
extension (introduced in version 05, documented in Section 3.3
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-05#section-3.3>).

I'd like to close out that discussion with a decision soon so we can
advance to a WG last call on the draft.

To summarise my thoughts on the param:

1. It can be can be used to improve usability – QR codes and NFC can be
used with this feature to create a more delightful user authorization
experience.
2. It may increase the potential phishing risk (which we can document),
as the user has less typing. This risk assessment is likely not
one-size-fits-all, it may vary widely due to different the different
potential applications of this standard.
3. The way it's worded makes it completely optional, leaving it up to
the discretion of the authorization server on whether to offer the
optimisation, allowing them to secure it as best they see it.
4. I do believe it is possible to design a secure user experiance that
includes this optimization.

I think on the balance, it's worthwhile feature to include, and one that
benefits interop. The authorization server has complete control over
whether to enable this feature – as Justin pointed out in the meeting, it
degrades really nicely – and should they enable it, they have control over
the user experiance and can add whatever phishing mitigations their
use-case warrants. Rarely is there a one-size-fits-all risk profile,
use-cases of this flow range widely from mass-market TV apps to
internal-only device bootstrapping by employees, so I don't think we should
be overly prescriptive.

Mitigating phishing is already something that is in the domain of the
authorization server with OAuth generally, and I know that this is an
extremely important consideration when designing user authorization flows.
This spec will be no exception to that, with or without this optimization.

That's my opinion. I'm keen to continue the discussion from Chicago and
reach rough consensus so we can progress forward.

Best,
William

[Mike Jones]

I think the spec is better with the (optional) user_code in it.

-- Mike

From: William Denniss [mailto:***@google.com]
Sent: Friday, April 28, 2017 1:39 PM
To: ***@ietf.org; John Bradley <***@ve7jtb.com>; Hannes Tschofenig <***@gmx.net>; Mike Jones <***@microsoft.com>
Subject: OAuth 2.0 Device Flow: IETF98 Follow-up

Thanks all who joined us in Chicago in person and remotely last month for the discussion on the device flow. [recording here<https://play.conf.meetecho.com/Playout/?session=IETF98-OAUTH-20170327-1710>, presentation starts at about 7min in].

The most contentious topic was addition of the user_code URI param extension (introduced in version 05, documented in Section 3.3<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-05#section-3.3>).

I'd like to close out that discussion with a decision soon so we can advance to a WG last call on the draft.

To summarise my thoughts on the param:

1. It can be can be used to improve usability – QR codes and NFC can be used with this feature to create a more delightful user authorization experience.
2. It may increase the potential phishing risk (which we can document), as the user has less typing. This risk assessment is likely not one-size-fits-all, it may vary widely due to different the different potential applications of this standard.
3. The way it's worded makes it completely optional, leaving it up to the discretion of the authorization server on whether to offer the optimisation, allowing them to secure it as best they see it.
4. I do believe it is possible to design a secure user experiance that includes this optimization.
I think on the balance, it's worthwhile feature to include, and one that benefits interop. The authorization server has complete control over whether to enable this feature – as Justin pointed out in the meeting, it degrades really nicely – and should they enable it, they have control over the user experiance and can add whatever phishing mitigations their use-case warrants. Rarely is there a one-size-fits-all risk profile, use-cases of this flow range widely from mass-market TV apps to internal-only device bootstrapping by employees, so I don't think we should be overly prescriptive.

Mitigating phishing is already something that is in the domain of the authorization server with OAuth generally, and I know that this is an extremely important consideration when designing user authorization flows. This spec will be no exception to that, with or without this optimization.

That's my opinion. I'm keen to continue the discussion from Chicago and reach rough consensus so we can progress forward.
Best,
William

[John Bradley]

I would like to keep the optional parameter. It is useful enough that if we don’t have it people will add it on there own as a custom parameter.
Better to document any issues.

John B.

Thanks all who joined us in Chicago in person and remotely last month for the discussion on the device flow. [recording here <https://play.conf.meetecho.com/Playout/?session=IETF98-OAUTH-20170327-1710>, presentation starts at about 7min in].
The most contentious topic was addition of the user_code URI param extension (introduced in version 05, documented in Section 3.3 <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-05#section-3.3>).
I'd like to close out that discussion with a decision soon so we can advance to a WG last call on the draft.
It can be can be used to improve usability – QR codes and NFC can be used with this feature to create a more delightful user authorization experience.
It may increase the potential phishing risk (which we can document), as the user has less typing. This risk assessment is likely not one-size-fits-all, it may vary widely due to different the different potential applications of this standard.
The way it's worded makes it completely optional, leaving it up to the discretion of the authorization server on whether to offer the optimisation, allowing them to secure it as best they see it.
I do believe it is possible to design a secure user experiance that includes this optimization.
I think on the balance, it's worthwhile feature to include, and one that benefits interop. The authorization server has complete control over whether to enable this feature – as Justin pointed out in the meeting, it degrades really nicely – and should they enable it, they have control over the user experiance and can add whatever phishing mitigations their use-case warrants. Rarely is there a one-size-fits-all risk profile, use-cases of this flow range widely from mass-market TV apps to internal-only device bootstrapping by employees, so I don't think we should be overly prescriptive.
Mitigating phishing is already something that is in the domain of the authorization server with OAuth generally, and I know that this is an extremely important consideration when designing user authorization flows. This spec will be no exception to that, with or without this optimization.
That's my opinion. I'm keen to continue the discussion from Chicago and reach rough consensus so we can progress forward.
Best,
William

[Justin Richer]

+1, documentation is better. Though we also need to keep in mind that
this was the justification for the password flow in 6749, which has been
abused all over the place (and continues to this day). Still, it would
be arguably worse without that so I'm good with keeping the parameter in
there as long as we're careful.

Namely: So long as the user code is *also* delivered separately to the
user, we would have interoperability between the two. What I don't think
we want is some systems that *require* the URI parameter on the approval
URL and other implementations that *forbid* it. That case could end up
with something like: I've got a set-top system that's incapable of
displaying a separate user code because it always assumes it's baked
into the URL, and then I try to put it on a server that requires the
code be entered separately.

The resulting spec needs to be clear that the box MUST be able to
display both the URL and the code separately, in case the URL does not
include the code. In fact, maybe we'd even want to introduce a new
parameter from the endpoint for the pre-composed URL:

user_code
REQUIRED. The end-user verification code.

verification_uri
REQUIRED. The end-user verification URI on the authorization
server. The URI should be short and easy to remember as end-
users will be asked to manually type it into their user-agent.

composite_verification_uri
OPTIONAL. The end-user verification URI with the end-user
verification code already included. See discussion in [blah]
for its use.

-- Justin

Post by John Bradley
I would like to keep the optional parameter. It is useful enough
that if we don’t have it people will add it on there own as a custom
parameter.
Better to document any issues.
John B.

Post by William Denniss
Thanks all who joined us in Chicago in person and remotely last month
for the discussion on the device flow. [recording here
<https://play.conf.meetecho.com/Playout/?session=IETF98-OAUTH-20170327-1710>,
presentation starts at about 7min in].
The most contentious topic was addition of the user_code URI param
extension (introduced in version 05, documented in Section 3.3
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-05#section-3.3>).
I'd like to close out that discussion with a decision soon so we can
advance to a WG last call on the draft.
1. It can be can be used to improve usability – QR codes and NFC can
be used with this feature to create a more delightful user
authorization experience.
2. It may increase the potential phishing risk (which we can
document), as the user has less typing. This risk assessment is
likely not one-size-fits-all, it may vary widely due to different
the different potential applications of this standard.
3. The way it's worded makes it completely optional, leaving it up
to the discretion of the authorization server on whether to offer
the optimisation, allowing them to secure it as best they see it.
4. I do believe it is possible to design a secure user experiance
that includes this optimization.
I think on the balance, it's worthwhile feature to include, and one
that benefits interop. The authorization server has complete control
over whether to enable this feature – as Justin pointed out in the
meeting, it degrades really nicely – and should they enable it, they
have control over the user experiance and can add whatever phishing
mitigations their use-case warrants. Rarely is there a
one-size-fits-all risk profile, use-cases of this flow range widely
from mass-market TV apps to internal-only device bootstrapping by
employees, so I don't think we should be overly prescriptive.
Mitigating phishing is already something that is in the domain of the
authorization server with OAuth generally, and I know that this is an
extremely important consideration when designing user authorization
flows. This spec will be no exception to that, with or without this
optimization.
That's my opinion. I'm keen to continue the discussion from Chicago
and reach rough consensus so we can progress forward.
Best,
William

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Torsten Lodderstedt]

+1 to keep the optional parameter along with clear wording regarding security risk and interoperability

+1, documentation is better. Though we also need to keep in mind that this was the justification for the password flow in 6749, which has been abused all over the place (and continues to this day). Still, it would be arguably worse without that so I'm good with keeping the parameter in there as long as we're careful.
Namely: So long as the user code is *also* delivered separately to the user, we would have interoperability between the two. What I don't think we want is some systems that *require* the URI parameter on the approval URL and other implementations that *forbid* it. That case could end up with something like: I've got a set-top system that's incapable of displaying a separate user code because it always assumes it's baked into the URL, and then I try to put it on a server that requires the code be entered separately.
user_code
REQUIRED. The end-user verification code.
verification_uri
REQUIRED. The end-user verification URI on the authorization
server. The URI should be short and easy to remember as end-
users will be asked to manually type it into their user-agent.
composite_verification_uri
OPTIONAL. The end-user verification URI with the end-user
verification code already included. See discussion in [blah]
for its use.
-- Justin

Post by John Bradley
I would like to keep the optional parameter. It is useful enough that if we don’t have it people will add it on there own as a custom parameter.
Better to document any issues.
John B.

Thanks all who joined us in Chicago in person and remotely last month for the discussion on the device flow. [recording here, presentation starts at about 7min in].
The most contentious topic was addition of the user_code URI param extension (introduced in version 05, documented in Section 3.3).
I'd like to close out that discussion with a decision soon so we can advance to a WG last call on the draft.
It can be can be used to improve usability – QR codes and NFC can be used with this feature to create a more delightful user authorization experience.
It may increase the potential phishing risk (which we can document), as the user has less typing. This risk assessment is likely not one-size-fits-all, it may vary widely due to different the different potential applications of this standard.
The way it's worded makes it completely optional, leaving it up to the discretion of the authorization server on whether to offer the optimisation, allowing them to secure it as best they see it.
I do believe it is possible to design a secure user experiance that includes this optimization.
I think on the balance, it's worthwhile feature to include, and one that benefits interop. The authorization server has complete control over whether to enable this feature – as Justin pointed out in the meeting, it degrades really nicely – and should they enable it, they have control over the user experiance and can add whatever phishing mitigations their use-case warrants. Rarely is there a one-size-fits-all risk profile, use-cases of this flow range widely from mass-market TV apps to internal-only device bootstrapping by employees, so I don't think we should be overly prescriptive.
Mitigating phishing is already something that is in the domain of the authorization server with OAuth generally, and I know that this is an extremely important consideration when designing user authorization flows. This spec will be no exception to that, with or without this optimization.
That's my opinion. I'm keen to continue the discussion from Chicago and reach rough consensus so we can progress forward.
Best,
William

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Simon Moffatt]

+1 for separate. The real world implementations we've seen tend to not
need the URL at all. Eg end user out of band is in a web application on
the their laptop/tablet and that app has a "pair device" area, where
they just enter the necessary code - so they don't even need to see/use
a URL from the device.

Having the code augmented in to the URL too opens up the ability for
that code to be logged on intermediary network devices.

SM

Post by Torsten Lodderstedt
+1 to keep the optional parameter along with clear wording regarding
security risk and interoperability

Post by Justin Richer
+1, documentation is better. Though we also need to keep in mind that
this was the justification for the password flow in 6749, which has
been abused all over the place (and continues to this day). Still, it
would be arguably worse without that so I'm good with keeping the
parameter in there as long as we're careful.
Namely: So long as the user code is *also* delivered separately to
the user, we would have interoperability between the two. What I
don't think we want is some systems that *require* the URI parameter
on the approval URL and other implementations that *forbid* it. That
case could end up with something like: I've got a set-top system
that's incapable of displaying a separate user code because it always
assumes it's baked into the URL, and then I try to put it on a server
that requires the code be entered separately.
The resulting spec needs to be clear that the box MUST be able to
display both the URL and the code separately, in case the URL does
not include the code. In fact, maybe we'd even want to introduce a
user_code
REQUIRED. The end-user verification code.
verification_uri
REQUIRED. The end-user verification URI on the authorization
server. The URI should be short and easy to remember as end-
users will be asked to manually type it into their user-agent.
composite_verification_uri
OPTIONAL. The end-user verification URI with the end-user
verification code already included. See discussion in [blah]
for its use.
-- Justin

Post by John Bradley
I would like to keep the optional parameter. It is useful enough
that if we don’t have it people will add it on there own as a custom
parameter.
Better to document any issues.
John B.

Post by William Denniss
Thanks all who joined us in Chicago in person and remotely last
month for the discussion on the device flow. [recording here
<https://play.conf.meetecho.com/Playout/?session=IETF98-OAUTH-20170327-1710>,
presentation starts at about 7min in].
The most contentious topic was addition of the user_code URI param
extension (introduced in version 05, documented in Section 3.3
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-05#section-3.3>).
I'd like to close out that discussion with a decision soon so we
can advance to a WG last call on the draft.
1. It can be can be used to improve usability – QR codes and NFC
can be used with this feature to create a more delightful user
authorization experience.
2. It may increase the potential phishing risk (which we can
document), as the user has less typing. This risk assessment is
likely not one-size-fits-all, it may vary widely due to
different the different potential applications of this standard.
3. The way it's worded makes it completely optional, leaving it up
to the discretion of the authorization server on whether to
offer the optimisation, allowing them to secure it as best they
see it.
4. I do believe it is possible to design a secure user experiance
that includes this optimization.
I think on the balance, it's worthwhile feature to include, and one
that benefits interop. The authorization server has complete
control over whether to enable this feature – as Justin pointed out
in the meeting, it degrades really nicely – and should they enable
it, they have control over the user experiance and can add whatever
phishing mitigations their use-case warrants. Rarely is there a
one-size-fits-all risk profile, use-cases of this flow range widely
from mass-market TV apps to internal-only device bootstrapping by
employees, so I don't think we should be overly prescriptive.
Mitigating phishing is already something that is in the domain of
the authorization server with OAuth generally, and I know that this
is an extremely important consideration when designing user
authorization flows. This spec will be no exception to that, with
or without this optimization.
That's my opinion. I'm keen to continue the discussion from Chicago
and reach rough consensus so we can progress forward.
Best,
William

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
ForgeRock <http://www.forgerock.com/> *Simon Moffatt*
Product Management | ForgeRock
*tel* [phone] | *e* ***@Forgerock.com
<mailto:***@forgerock.com>
*skype* simon.moffatt | *web* www.forgerock.com
<http://www.forgerock.com/> | *twitter* @simonmoffatt


ForgeRock Live 2017 <https://summits.forgerock.com/>

[Rifaat Shekh-Yusef]

All,

Hannes and I discussed the Device Flow draft. Based on the mailing list
feedback, we see that there is a good support for keeping the "user_code"
parameter in, but there is a need to document the security implication of
this feature. If anyone is against keeping this feature, please speak up
now.


*William,*

Can you please update the document based on the feedback you received so
far?
We would like to start a WGLC after we get the new version of the draft.


We also have few comments on v05 of the draft:

Section 3.3, second paragraph:

The document should explicitly state that this step must be done over an
HTTPS channel.

Also, the paragraph is talking about an "end-user" performing the
procedure. This could be done by an administrator that has a long list
of devices, e.g. IoT devices, that support this mechanism. So, maybe the
document should clearly state that too.


Nits:

Section 3.3, 3rd paragraph, second line:
Remove the "a" before "the browser"

Section 5.2, 1st paragraph, second line:
Remove the word "they" after "attacker"

Regards,
Rifaat & Hannes

Post by Simon Moffatt
+1 for separate. The real world implementations we've seen tend to not
need the URL at all. Eg end user out of band is in a web application on
the their laptop/tablet and that app has a "pair device" area, where they
just enter the necessary code - so they don't even need to see/use a URL
from the device.
Having the code augmented in to the URL too opens up the ability for that
code to be logged on intermediary network devices.
SM
+1 to keep the optional parameter along with clear wording regarding
security risk and interoperability
+1, documentation is better. Though we also need to keep in mind that this
was the justification for the password flow in 6749, which has been abused
all over the place (and continues to this day). Still, it would be arguably
worse without that so I'm good with keeping the parameter in there as long
as we're careful.
Namely: So long as the user code is *also* delivered separately to the
user, we would have interoperability between the two. What I don't think we
want is some systems that *require* the URI parameter on the approval URL
and other implementations that *forbid* it. That case could end up with
something like: I've got a set-top system that's incapable of displaying a
separate user code because it always assumes it's baked into the URL, and
then I try to put it on a server that requires the code be entered
separately.
The resulting spec needs to be clear that the box MUST be able to display
both the URL and the code separately, in case the URL does not include the
code. In fact, maybe we'd even want to introduce a new parameter from the
user_code
REQUIRED. The end-user verification code.
verification_uri
REQUIRED. The end-user verification URI on the authorization
server. The URI should be short and easy to remember as end-
users will be asked to manually type it into their user-agent.
composite_verification_uri
OPTIONAL. The end-user verification URI with the end-user
verification code already included. See discussion in [blah]
for its use.
-- Justin
I would like to keep the optional parameter. It is useful enough that if
we don’t have it people will add it on there own as a custom parameter.
Better to document any issues.
John B.
Thanks all who joined us in Chicago in person and remotely last month for
the discussion on the device flow. [recording here
<https://play.conf.meetecho.com/Playout/?session=IETF98-OAUTH-20170327-1710>,
presentation starts at about 7min in].
The most contentious topic was addition of the user_code URI param
extension (introduced in version 05, documented in Section 3.3
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-05#section-3.3>
).
I'd like to close out that discussion with a decision soon so we can
advance to a WG last call on the draft.
1. It can be can be used to improve usability – QR codes and NFC can
be used with this feature to create a more delightful user authorization
experience.
2. It may increase the potential phishing risk (which we can
document), as the user has less typing. This risk assessment is likely not
one-size-fits-all, it may vary widely due to different the different
potential applications of this standard.
3. The way it's worded makes it completely optional, leaving it up to
the discretion of the authorization server on whether to offer the
optimisation, allowing them to secure it as best they see it.
4. I do believe it is possible to design a secure user experiance that
includes this optimization.
I think on the balance, it's worthwhile feature to include, and one that
benefits interop. The authorization server has complete control over
whether to enable this feature – as Justin pointed out in the meeting, it
degrades really nicely – and should they enable it, they have control over
the user experiance and can add whatever phishing mitigations their
use-case warrants. Rarely is there a one-size-fits-all risk profile,
use-cases of this flow range widely from mass-market TV apps to
internal-only device bootstrapping by employees, so I don't think we should
be overly prescriptive.
Mitigating phishing is already something that is in the domain of the
authorization server with OAuth generally, and I know that this is an
extremely important consideration when designing user authorization flows.
This spec will be no exception to that, with or without this optimization.
That's my opinion. I'm keen to continue the discussion from Chicago and
reach rough consensus so we can progress forward.
Best,
William
_______________________________________________
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
--
[image: ForgeRock] <http://www.forgerock.com/> *Simon Moffatt*
Product Management | ForgeRock
*tel* [phone] <+44%207903%20347240> | *e*
*skype* simon.moffatt | *web* www.forgerock.com | *twitter*
@simonmoffatt
[image: ForgeRock Live 2017] <https://summits.forgerock.com/>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[William Denniss]

Rifaat and Hannes,

Thank you for your review, and for the consensus judgement. Version v06
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06> has been
posted that actions this feedback.

I would also like to see a WGLC issued on the document.

Best,
William

Post by Rifaat Shekh-Yusef
All,
Hannes and I discussed the Device Flow draft. Based on the mailing list
feedback, we see that there is a good support for keeping the "user_code"
parameter in, but there is a need to document the security implication of
this feature. If anyone is against keeping this feature, please speak up
now.
*William,*
Can you please update the document based on the feedback you received so
far?
We would like to start a WGLC after we get the new version of the draft.
The document should explicitly state that this step must be done over an
HTTPS channel.
Also, the paragraph is talking about an "end-user" performing the
procedure. This could be done by an administrator that has a long list
of devices, e.g. IoT devices, that support this mechanism. So, maybe the
document should clearly state that too.
Remove the "a" before "the browser"
Remove the word "they" after "attacker"
Regards,
Rifaat & Hannes

Post by Simon Moffatt
+1 for separate. The real world implementations we've seen tend to not
need the URL at all. Eg end user out of band is in a web application on
the their laptop/tablet and that app has a "pair device" area, where they
just enter the necessary code - so they don't even need to see/use a URL
from the device.
Having the code augmented in to the URL too opens up the ability for that
code to be logged on intermediary network devices.
SM
+1 to keep the optional parameter along with clear wording regarding
security risk and interoperability
+1, documentation is better. Though we also need to keep in mind that
this was the justification for the password flow in 6749, which has been
abused all over the place (and continues to this day). Still, it would be
arguably worse without that so I'm good with keeping the parameter in there
as long as we're careful.
Namely: So long as the user code is *also* delivered separately to the
user, we would have interoperability between the two. What I don't think we
want is some systems that *require* the URI parameter on the approval URL
and other implementations that *forbid* it. That case could end up with
something like: I've got a set-top system that's incapable of displaying a
separate user code because it always assumes it's baked into the URL, and
then I try to put it on a server that requires the code be entered
separately.
The resulting spec needs to be clear that the box MUST be able to display
both the URL and the code separately, in case the URL does not include the
code. In fact, maybe we'd even want to introduce a new parameter from the
user_code
REQUIRED. The end-user verification code.
verification_uri
REQUIRED. The end-user verification URI on the authorization
server. The URI should be short and easy to remember as end-
users will be asked to manually type it into their user-agent.
composite_verification_uri
OPTIONAL. The end-user verification URI with the end-user
verification code already included. See discussion in [blah]
for its use.
-- Justin
I would like to keep the optional parameter. It is useful enough that
if we don’t have it people will add it on there own as a custom parameter.
Better to document any issues.
John B.
Thanks all who joined us in Chicago in person and remotely last month for
the discussion on the device flow. [recording here
<https://play.conf.meetecho.com/Playout/?session=IETF98-OAUTH-20170327-1710>,
presentation starts at about 7min in].
The most contentious topic was addition of the user_code URI param
extension (introduced in version 05, documented in Section 3.3
<https://tools.ietf.org/html/draft-ietf-oauth-device-flow-05#section-3.3>
).
I'd like to close out that discussion with a decision soon so we can
advance to a WG last call on the draft.
1. It can be can be used to improve usability – QR codes and NFC can
be used with this feature to create a more delightful user authorization
experience.
2. It may increase the potential phishing risk (which we can
document), as the user has less typing. This risk assessment is likely not
one-size-fits-all, it may vary widely due to different the different
potential applications of this standard.
3. The way it's worded makes it completely optional, leaving it up to
the discretion of the authorization server on whether to offer the
optimisation, allowing them to secure it as best they see it.
4. I do believe it is possible to design a secure user experiance
that includes this optimization.
I think on the balance, it's worthwhile feature to include, and one that
benefits interop. The authorization server has complete control over
whether to enable this feature – as Justin pointed out in the meeting, it
degrades really nicely – and should they enable it, they have control over
the user experiance and can add whatever phishing mitigations their
use-case warrants. Rarely is there a one-size-fits-all risk profile,
use-cases of this flow range widely from mass-market TV apps to
internal-only device bootstrapping by employees, so I don't think we should
be overly prescriptive.
Mitigating phishing is already something that is in the domain of the
authorization server with OAuth generally, and I know that this is an
extremely important consideration when designing user authorization flows.
This spec will be no exception to that, with or without this optimization.
That's my opinion. I'm keen to continue the discussion from Chicago and
reach rough consensus so we can progress forward.
Best,
William
_______________________________________________
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
--
[image: ForgeRock] <http://www.forgerock.com/> *Simon Moffatt*
Product Management | ForgeRock
*tel* [phone] <+44%207903%20347240> | *e*
*skype* simon.moffatt | *web* www.forgerock.com | *twitter*
@simonmoffatt
[image: ForgeRock Live 2017] <https://summits.forgerock.com/>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth