Yeah, unfortunately the WWW-Authenticate solution advertising an AS has bad
(fatal) security problems. That's the underlying reason/urgency behind a
separate services discovery mechanism. It's not that we ignored
WWW-Authenticate, and in fact I'm in process of ripping that mechanism out of a
Sergey,
A hypermedia-driven (RESTful) API should be able to use OAuth. Unfortunately,
OAuth does not have a RESTful design.
Most APIs require client apps (not just the user) to be pre-registered with the
service. That seems to have made hypermedia-driven design less important - if a
client app
I am stepping down from my role as editor of the MAC token specification. I do
not intend to participate in this work moving forward. I will forward my notes
to the next editor if requested.
EH
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org
In order to make the prescribed change, new text is needed:
* New subsection for section 7 (Accessing Protected Resources) providing
guidelines for use of the new 'resource access error response' error registry:
1. What are the valid cases in which a 'resource access error response' may
be r
Hi all,
on May 8th we called for consensus on an open issue regarding the location of
the error registry. Here is the call for comments:
http://www.ietf.org/mail-archive/web/oauth/current/msg08952.html.
Thank you all for the feedback. The consensus is to create the registry in the
core docum
The danger is a bad resource, If that can redirect the client to a arbitrary
AS to phish the resource owner's credentials that is a bad thing.
The presumption is that the client knows where the trusted AS for that resource
is, and if it needs to discover it that is a much bigger issue.
In the
The Web Authorization Protocol (oauth) working group in the Security Area of
the IETF has been rechartered. For additional information, please contact the
Area Directors or the working group Chairs.
Web Authorization Protocol (oauth)
--
Current Status: Ac
Bill,
it might be me misreading the Implicit Grant Flow, but I understood it like
this:
1. client tries to get a resource from server;
2. server redirects client to auth-service;
3. client authenticates against auth-service (HTTP Basic or whatever);
4. auth-service redirects client back to the re
I was about to write about the same thing. See
http://openid.net/specs/openid-connect-messages-1_0.html#id_token for the
definition of "acr" (Authentication Context Class Reference) as used by OpenID
Connect.
It's not clear to me that this should move into the JWT spec itself, as I'd
rather w
We added on in openID Connect.
acr : Though that is intended as a class reference for things like FICAM LoA 2
etc. You could make class references that only defined the primary
authenticator.
The question is if there is enough consensus to put it in the JWT spec rather
than in things profil
You can hard configure it into your client, that's safe. The problem comes
when the client can be sent to an arbitrary, possibly phishing, site to do
authentication. If the client supports the password grant then it probably
just hands in the username and password without user interaction.
-
In my scenario I control both the resource provider and the token issuer
and I'm fine with the resource provider knowing the issuer. So, discovery
is not needed. Or do I miss something?
On Tue, May 15, 2012 at 6:04 PM, William Mills wrote:
> Yes, what you're running across here is the "discovery
Yes, what you're running across here is the "discovery" problem. How do you
discover the authentication endpoints for a service. Unfortunately it turns
out returning that as part of the 401 has big security concerns. It's still
being figured out.
>
> From:
Justin,
I want to let client (API client, not OAuth Client) know less to get the
job done. The service should ideally be able to encode everything required
in a URL and give it to the client. This is what is described in the
Implicit Grant Flow [
http://tools.ietf.org/html/draft-ietf-oauth-v2-26#s
Hi,
Apologies if the OAuth list is not the right place to ask this question, but
I'm trying to understand why JWT doesn't have an "Authentication Context" like
reserved claim name (such as present in SAML). Knowing the primary
authentication method used to obtain the JWT seems just as fundamen
This kind of fully automated approach isn't solved yet. OAuth isn't
quite as simple as HTTP Basic and its kin, where the user agent can
collect everything it needs directly and just push it back to the
protected URL. In order for this to truly work, you need to have not
just a pointer to the is
While designing a hypermedia-driven API I'm evaluating possibilities to use
OAuth Bearer tokens for claims-based authorization. Currently I struggle
with how to communicate to the API client the way to obtain the token. In a
hypermedia-driven manner I don't want the API client to get this
informati
17 matches
Mail list logo
