WFM.
This will be the new text for 7.2 unless someone has any additional feedback or
concerns.
This closes my issue with the new error registry changes.
EH
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Thursday, June 14, 2012 6:15 PM
To: Eran Hammer; oauth@ietf.org WG (oauth@ietf
Thanks for writing the text below. It looks fine to me. About adding the
other error parameters as suggestions, that seems like a reasonable thing to
do. How about the text at the end below, which adds mentions of
error_description and error_uri?
7.2. Error Response
If a resource ac
Mike - if you want to add the other error parameters as suggestions, that would
be fine by me.
EH
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer
> Sent: Thursday, June 14, 2012 3:23 PM
> To: Mike Jones; oauth@ietf.org WG (oa
7.2. Error Response
If a resource access request fails, the resource server SHOULD inform
the client of the error. While the specifics of such error responses
are beyond the scope of this specification, this documents establishes
a common registry for error values to be shared among
It seems to me that a single table is a better way to accomplish the goals set
by the working group. The entire reason for adding the new location was based
on the assumption that there will be overlap.
EH
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Thursday, June 14, 2012 3:0
That sounds fine to me. If you want to take a stab at proposed text, have at
it!
-- Mike
From: Eran Hammer
Sent: 6/14/2012 2:59 PM
To: oauth@ietf.org WG (oauth@ietf.org)
Subject: [OAUTH-WG] Section 7.2
One simple solution is to define the new error location as
Yes, we already have multiple registries, but only one for errors. When an
error code can be used in more than one usage location, having one will make
the registrations simpler and it may be somewhat more apparent how the error
code is used.
The two structures are equivalent, but it seems to
One simple solution is to define the new error location as an opt-in registry
for oauth-centric token authentication methods. Instead of requiring new
schemes to use it and deal with all the confusing qualifications, just narrowly
define the new registry as a service for new token authentication
We already have multiple registries. This one is about error codes only. I
don't think the overlap is clear at this point between errors on the core
endpoints vs error on the bearer and future auth schemes opting into this
registry. So it is hard to tell which format would be better. The main qu
We might be able to combine these, but to me it really does make sense to have
one registry for OAuth 2 core extensions to the frameowrk and one for the auth
profiles. The downside of this would be duplication between the two. If we
think there will be significant overlap then I think they sho
I'm thinking about what the appropriate updates to 7.2 are. Your question
about "What if the parameter is named 'err' rather than 'error'?" is a fair
one, for instance. I'll also target proposed updates to that for Monday.
As to the question of one OAuth Errors registry versus four, as I suspe
Hi Hannes,
You stated a preference for separate registries below, but that was a larger
change to the OAuth Core spec than the current draft, which added a fourth
error usage location "resource access error response" to the registry. To my
knowledge, the consensus call didn't ask people to exp
Updated for examples, the editorial issues like replacing link header for lrdd
where it appears, fixing authenticate->authorize.
Thanks for the feedback so far.
-bill
--
A new version of I-D, draft-wmills-oauth-lrdd-01.txt
has been successfully submitted by William Mills and
Sounds good.
Any progress on a revised 7.2? I'd like to get clarity on that so we can agree
on new text and close the issue along with the ABNF.
EH
> -Original Message-
> From: Mike Jones [mailto:michael.jo...@microsoft.com]
> Sent: Thursday, June 14, 2012 2:18 PM
> To: Eran Hammer
> Cc
FYI, Eran, I'm going to hold off sending you proposed updated ABNF text for a
few more days to let the discussions continue and consensus to build. I'm
currently mentally targeting sending proposed draft updates Monday.
Best wishes,
This is a fairly well known (hopefully by now) issue. We, at the OpenID
Foundation, call it "access_token phishing" attack these days. See:
http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
Nov Matake has actually built the code on iPhone to verify the problem, and
has
FWIW, the reason we ultimately went with JSON was that it removed stumbling
blocks around implementation and sheer spec volume. When we used straight XRD,
we found that we had to put a full worked example in an appendix so it didn't
impede the flow of the spec, and implementers reported to us th
Dear Facebook Security Team and OAuth Standard group,
We are a research team in Microsoft Research. In January, 2011, we reported
a vulnerability in Facebook Connect which allowed everyone to sign into
Facebook-secured relying parties without password. It was promptly fixed
after reporting. (
http
That works for me Torsten, thanks.
The “SHOULD”s make it interesting for the clients. It seems that the
client developer will need to know how the individual AS’s are handling it.
I pasted a couple of examples below where the terms “SHOULD” and “SHOULD
NOT” are used. Both of these indicate to
19 matches
Mail list logo
