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”. 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:sakim...@gmail.com]
Sent: Thursday, January 21, 2016 6:24 AM
To: Justin Richer <jric...@mit.edu>; Mike Jones <michael.jo...@microsoft.com>
Cc: William Denniss <wdenn...@google.com>; <oauth@ietf.org> <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 . 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 <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
<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]
Sent: Wednesday, January 20, 2016 11:17 PM
To: Mike Jones
<michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>>; William
Denniss <wdenn...@google.com<mailto:wdenn...@google.com>>; Justin Richer
<jric...@mit.edu<mailto:jric...@mit.edu>>
Cc: 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
<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: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 <jric...@mit.edu<mailto:jric...@mit.edu>>
Cc: 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
<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)
Nat explains his document as an example of the work that has to be
done
in the area of discovery, which is a topic that has been identified
as necessary for interoperability since many years but so far there
was not time to work on it. Mike, John and Nat are working on a new
document that describes additional discovery-relevant components.
Poll: 19 for / zero against / 4 persons need more information.
The document discussed there was
https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a simple
(only 1-page!) but a very powerful document that nudges towards HATEOAS which
is at the core of RESTful-ness. It also mitigates the Mix-up attack without
introducing the concept of issuer which is not in RFC6749. It is also good for
selecting different endpoints depending on the user authentication and
authorization results and more privacy sensitive than pre-announced Discovery
document. It also allows you to find to which protected resource endpoint you
can use the access token against.
In the last sentence of the minutes, it talks about "a new document that
describes additional discovery-relevant components". This is
https://tools.ietf.org/html/draft-jones-oauth-discovery-00. It went for the
call for adoption. However, it is only a half of the story. I believe
https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was discussed at
IETF 94 and had support there should be adopted as well.
Nat Sakimura
2016年1月20日(水) 12:05 Nat Sakimura
<sakim...@gmail.com<mailto:sakim...@gmail.com>>:
Thanks Hannes.
I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which
was discussed in Yokohama, and was largely in agreement if my recollection is
correct. Why is it not in the call for adoption?
2016年1月19日(火) 20:39 Hannes Tschofenig
<hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>>:
Hi all,
we have submitted our new charter to the IESG (see
http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and
since some IESG members like to see an updated list of milestones as
well. For this reason, based on a suggestion from Barry, we are also
starting a call for adoption concurrently with the review of the charter
text by the IESG.
We will post separate mails on the individual documents. Your feedback
is important! Please take the time to look at the documents and provide
your feedback.
Ciao
Hannes & Derek
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
