I like the “from which the authorization server's
configuration information location can be
derived” language. Thanks. I’ll plan to
incorporate that the next time the draft is revised.
-- Mike
*From:*Brian Campbell
[mailto:<mailto:bcampb...@pingidentity.com>bcampb...@pingidentity.com
<mailto:bcampb...@pingidentity.com>]
*Sent:* Friday, January 22, 2016 3:26 PM
*To:* Nat Sakimura
<<mailto:sakim...@gmail.com>sakim...@gmail.com
<mailto:sakim...@gmail.com>>
*Cc:* Mike Jones
<<mailto:michael.jo...@microsoft.com>michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>; Justin
Richer <<mailto:jric...@mit.edu>jric...@mit.edu
<mailto:jric...@mit.edu>>; <oauth@ietf.org
<mailto:oauth@ietf.org>> <oauth@ietf.org
<mailto:oauth@ietf.org>>
*Subject:* Re: [OAUTH-WG] Call for Adoption
I agree that the language describing OAuth issuer
could and should be improved. The text now reads
like it is the exact and full URL where the
metadata/discovery document is located. Perhaps
something more like "the URL from which the
authorization server's configuration information
location can be derived" and explain that adding
the .well-known bits to the issuer is where the
configuration information can actually be found.
On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura
<<mailto:sakim...@gmail.com>sakim...@gmail.com
<mailto:sakim...@gmail.com>> wrote:
Re: iss. I discussed this a bit with Nov in
more details. It probably is a sloppy
language of the specs that is making it
difficult to read what you wanted to achieve.
In mix-up-mitigation draft, OAuth issuer is
"the URL of the authorization server's
configuration information location". In OAuth
discovery draft, there is something called
"OAuth 2.0 Configuration Information Location
URL", which is equal to "OpenID Connect Issuer".
When I wrote the statement, I thought you
were pointing to the URL that you can
actually pull the configuration information
by "the URL of the authorizaiton server's
configuration information location" since
otherwise you would have used the term "OAuth
2.0 Configuration Information Location URL".
But after all, you probably meant these two
are the same. Then I would strongly recommend
to fix the language.
Now, even If that is the case, the
relationship like
·iss + .well-know/openid-configuration =
Connect OP config endoint
·OAuth config endpoint -
.well-known/openid-configuration = OAuth iss
is very confusing.
You also claim that your approach is simpler,
but to me, your approach seem to be overly
complex. It requires discovery and the check
for the value of the discovered config
information to work as the mitigation.
(Right. Draft -01 does not have it, so it
does not solve the mix-up issue.) With
oauth-meta, you do not need it.
Finally, your point that HATEOAS reminds you
of WSDL, it is not. If you want to have
something similar to WSDL in REST API area,
it is Swagger. (Actually, it is gaining a lot
of momentum recently, but that's beside the
fact ;-). And the point here is not the
format but the fact that we need to have a
way to associate metadata to the data. The
root cause of this mix-up attack is that the
metadata and data is not associated properly.
We have a standard way of associating the
data and metadata with link-rel such as
RFC5988 so why not use it? Link-rel-href
pattern is used a lot now. Most modern web
pages actually have it. Using a proper way to
associate metadata with data will save you
from a lot of other attacks in the future.
Instead of doing patch works, we should solve
it architecturally.
Nat
2016年1月22日(金) 10:34 Mike Jones
<<mailto:michael.jo...@microsoft.com>michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>:
Nat, I’m confused by this statement in
the message you reference “Unfortunately,
this does not match the value of OAuth
issuer defined in Section 2
of draft-jones-oauth-mix-up-mitigation-01
nor the 'iss' returned as specified in
3.1. As such, validation as specified in
bullet 1 of Section 4 fails in Google's
case -- OR it means that the document is
internally inconsistent.”. The issuer
definition in draft-jones-oauth-discovery
is 100% compatible with the one in OpenID
Connect Discovery, by design. In the
Google example, both the OpenID issuer
and the OAuth issuer values would be the
string
“<https://accounts.google.com>https://accounts.google.com”.
What is the inconsistency that you perceive?
The discussion of the duplication problem
happened in the private meetings in Yokohama.
I will admit, in Yokohama, I didn’t speak
up in the public meetings to point out
that a simpler alternative to oauth-meta
was already being discussed there in
private, because then I would have had to
talk about the security issues, which
we’d decided not to publicly do at that
point. So I stayed silent during the
poll, out of politeness. Perhaps I should
have found a way to say something then
anyway, but that’s water under the bridge
now.
Finally, for what it’s worth, the HATEOAS
stuff reminds me far too much of Web
Services Description Language (WSDL) –
part of the complexity baggage that
helped sink Web Services. The use of
“link rel” to define an interaction
vocabulary and publish endpoints for that
vocabulary seems pretty baroque and
reminiscent of “microformats” – another
cute “Webby” innovation that never caught
on. The industry has pretty much voted
with its feet and is using JSON for
publishing discovery data structures –
not “link rel”. I am against us
reverting to the “link rel” proposal from
2008 that never caught on when JSON is
simpler and does a better job.
-- Mike
*From:*Nat Sakimura
[mailto:<mailto:sakim...@gmail.com>sakim...@gmail.com
<mailto:sakim...@gmail.com>]
*Sent:* Thursday, January 21, 2016 6:24 AM
*To:* Justin Richer
<<mailto:jric...@mit.edu>jric...@mit.edu
<mailto:jric...@mit.edu>>; Mike Jones
<<mailto:michael.jo...@microsoft.com>michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>
*Cc:* William Denniss
<<mailto:wdenn...@google.com>wdenn...@google.com
<mailto:wdenn...@google.com>>;
<<mailto:oauth@ietf.org>oauth@ietf.org
<mailto:oauth@ietf.org>>
<<mailto:oauth@ietf.org>oauth@ietf.org
<mailto:oauth@ietf.org>>
*Subject:* Re: [OAUTH-WG] Call for Adoption
Mike,
You just criticize my draft. That's ok,
but I would really like to get some
response to my questions stated in
<https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html>https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html
.
To me, it just does not seem to work, and
the combination of the oauth-meta and
PKCE seems to be much more elegan, nicer,
and much simpler to implement. If you
just give up the dynamic response at the
authorization endpoint, then you even do
not have to touch the code but just
change a config file.
Please convince me by answering to my
questions.
For the record of Yokohama, I do not
recall much about duplication in OAuth
session. The poll in the room was 19 for
/ zero against / 4 persons need more
information. Indeed, it is not
duplicating much. And if you move to a
new model without pre-configured
discovery, it is not duplicating any but
the resource endpoint URI, which is
optional and is for the cases where the
client did not know the concrete resource
endpoint to start with.
I understand your usecases always start
from a concrete endpoint location. Mine
do not. In a four party model, it is
likely not. The user just want to have
the service to fetch his data from some
resource endpoint. He just hits the
service. He does not hit the resource
endpoint directly. For example, in the
case of a consumer using a personal
finance platform (PFP)to manage his
pension fund, he hits the PFP and not the
Pension fund. Assuming that the pension
fund has delegated the authorization
control to the authorization server,
then, the authorization server should
return both the access token and the
endpoint of the pension fund so that the
PFP can pull the data using them. A
similar model holds for personal health
service and health care providers.
Best,
Nat
2016年1月21日(木) 21:18 Justin Richer
<<mailto:jric...@mit.edu>jric...@mit.edu
<mailto:jric...@mit.edu>>:
Convergence is exactly what I’m
arguing for, though. These things
ought to work together.
— Justin
On Jan 21, 2016, at 2:55 AM, Mike
Jones
<<mailto:michael.jo...@microsoft.com>michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>
wrote:
My memory of the discussions of
the oauth-meta draft in Yokohama
were that many people felt that
it was unnecessarily dynamically
duplicating a lot of information
that the client already had.
Most of us that were aware of the
attacks then were in favor of a
more targeted, minimal approach.
You were listened to in Yokohama,
but that didn’t necessarily mean
that people agreed with the
approach. Participants were
already aware of the oauth-meta
proposal in Darmstadt but no one
spoke up in favor of it that I
can recall. Rather, I think
people were thinking that “less
is more”.
There have also been discussions
in the last day about how
dynamically returning a resource
URL, which oauth-meta does, is
both unnecessary (since the
client initiated the resource
authorization already knowing
what resource it wants to access)
and often problematic, since many
authorization servers can
authorize access to multiple
resources. If anything, the
client should be telling the
authorization server what
resource it wants to access – not
the other way around.
I’m not saying that there aren’t
some good ideas in the oauth-meta
draft – I’m sure there are, just
as there are in the approach
designed by the participants in
Darmstadt. While I volunteered to
write the first draft of the
mix-up-mitigation approach, it
really reflects something a lot
of people have already bought
into – as evidenced in the
passion in the high-volume
“Mix-Up About The Mix-Up
Mitigation” thread, and not just
my personal project.
If you think there are things
missing or wrong in the
mix-up-mitigation draft, please
say what they are. That will
help us quickly converge on a
solution that will work for everyone.
Sincerely,
-- Mike
*From:*Nat Sakimura
[<mailto:sakim...@gmail.com>mailto:sakim...@gmail.com]
*Sent:* Wednesday, January 20,
2016 11:17 PM
*To:* Mike Jones
<<mailto:michael.jo...@microsoft.com>michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>;
William Denniss
<<mailto:wdenn...@google.com>wdenn...@google.com
<mailto:wdenn...@google.com>>;
Justin Richer
<<mailto:jric...@mit.edu>jric...@mit.edu
<mailto:jric...@mit.edu>>
*Cc:*
<mailto:oauth@ietf.org>oauth@ietf.org
<mailto:oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] Call
for Adoption
Hi Mike.
Conversely, I would like to ask
why this approach does not work
for Mix-up attack. As Nov stated,
we in fact have discussed the
approach in quite a length back
in Yokohama. I really would like
to know why it does not work.
Besides, for oauth-meta approach,
mix-up attack is only one of the
thing it solves.
Nat Sakimura
2016年1月21日(木) 16:02 Mike
Jones
<<mailto:michael.jo...@microsoft.com>michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>:
Not to be negative, but I
disagree with adopting
draft-sakimura-oauth-meta. We
should define and promote one
mitigation approach to the
mix-up attacks. Having two
would confuse implementers
and cause compatibility
problems – reducing overall
security.
The approach defined in
draft-jones-oauth-mix-up-mitigation
was created in collaboration
with the security researchers
who identified the problems
in the first place, was
vigorously discussed in the
security meeting Hannes and
Torsten held in Darmstadt,
and has been since refined
based on substantial input
from the working group. And
at least three implementers
have already stated that
they’ve implemented it. I’m
not saying that it’s, but if
there are things missing or
things that need to be
improved in our approach, we
should do it there, rather
introducing a competing approach.
Also, standard OAuth
deployments register the
client and then use the
information gathered at
registration time for
subsequent protocol
interactions. They do not
need all the configuration
information for the
authorization server to be
retransmitted at runtime. The
oauth-meta draft goes too far
in that direction, at least
as I see it. Returning
things two ways creates its
own problems, as discussed in
the Duplicate Information
Attacks security
considerations section (7.2)
of the mix-up-mitigation draft.
I’ll note that the
mix-up-mitigation approach is
compatible with existing
practice in both static and
dynamic metadata discovery.
Replying to Justin’s comment
that “It's the pre-configured
discovery document that's at
the root of the mix-up attack
in the first place” – this is
not the case. The attacks
can be performed without
either discovery or dynamic
registration.
I would be interested in
hearing a technical
discussion on whether there
are aspects of the oauth-meta
approach that mitigate
aspects of the attacks that
the mix-up-mitigation
approach does not. That
could help inform whether
there are additional things
we should add to or change in
the mix-up draft.
-- Mike
*From:*OAuth
[mailto:<mailto:oauth-boun...@ietf.org>oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>]
*On Behalf Of *William Denniss
*Sent:* Wednesday, January
20, 2016 10:37 PM
*To:* Justin Richer
<<mailto:jric...@mit.edu>jric...@mit.edu
<mailto:jric...@mit.edu>>
*Cc:*
<mailto:oauth@ietf.org>oauth@ietf.org
<mailto:oauth@ietf.org>
*Subject:* Re: [OAUTH-WG]
Call for Adoption
+1 to adopt this, and I agree
with Justin's comments.
On Wed, Jan 20, 2016 at 9:53
PM, Justin Richer
<<mailto:jric...@mit.edu>jric...@mit.edu
<mailto:jric...@mit.edu>> wrote:
+1
Inline discovery and
pre-configured discovery
(ie, .well-known) should
at the very least be
compatible and developed
together. It's the
pre-configured discovery
document that's at the
root of the mix-up attack
in the first place.
-- Justin
On 1/19/2016 10:30 PM,
Nat Sakimura wrote:
Just to give more
context, at IETF 94,
I have done a
presentation on
discovery.
According to the
minutes,
(f) Discovery (Nat)
