I favor this approach as well. It feels cleaner to me to have a
separation of purposes here. The two endpoints could always be collapsed
in a particular implementation -- I've seen several OAuth 1.0
implementations that do just this, using a URL parameter to
differentiate between the request,
Also, when implementing OAuth 2.0 people will take into account existing
parameters and will avoid them, they will chose other parameter names (if
possible). If the next version of OAuth, let's call it 2.1, adds a few new
parameters, how can we chose them so they don't collide with extra
+1 to the Device idea. About a year ago I brought up the idea of
having an instance identifier as an OAuth extension, but that never got
traction and I dropped the thread.
-- justin
On Mon, 2010-04-19 at 09:03 -0400, Torsten Lodderstedt wrote:
+1 to #1 (as starting point)
In my opinion, the
I was surprised that this announcement didn't garner more commentary
from the list here, as this decision worries me a little bit. There are
a lot of components of the OAuth protocol that aren't stabilized into a
real standard yet, and I'm worried that the Facebook implementation of
OAuth 2.0 will
Interesting work. So as each app upgrades its support from OAuth1 to
OAuth2, it exchanges its old tokens for new ones once for each user,
right? Then the app in question is effectively going to have to speak
both flavors of OAuth to do this one-time upgrade. I always assumed that
apps would just
I'd personally rather see something flatter, even with an implied root
namespace defined in the spec. Maybe like:
oauth
access_tokenasdfasoij234f/access_token
refresh_token2f098jadfasdfasdf/refresh_token
expires_in300/expires_in
/oauth
Mirroring the key-value format for the
1. ++
2. ++
3. ++
4. ++ as a part of 3., otherwise --
-- justin
On Fri, 2010-06-04 at 12:58 -0400, George Fletcher wrote:
Could I conclude then that we are all in agreement? :)
1. OAuth 2.0 should not require a structured token (i.e. don't break
existing use cases)
2. OAuth 2.0 should
One of the things that I found particularly useful with working with
OAuth1 was the ability to perform an entire transaction through URL
parameter manipulation. This is why I wholly support keeping the client
id and secret fields in the client auth flow and the username and
password fields in the
+1
Propose we have other encodings as extensions, then.
-- justin
On Thu, 2010-06-10 at 16:29 -0400, Eran Hammer-Lahav wrote:
After taking a break from our previous debate(s) on the issue of which
response format to support, I would like to suggest the following:
- Support a single
Along these lines, I'd like to propose an extension for per-client
instance information to be passed from a client to the server. Things
like a human-readable client name/description, instance name/description
(could be tied to host name, ip, label like home or Work), and even
something like a
,
allowing ad-hoc registration, and allowing unknown client ids before we
can answer this question.
-- Justin
On Fri, 2010-06-11 at 11:35 -0400, Christian Scholz wrote:
Hi!
Am 11.06.10 17:05, schrieb Justin Richer:
Along these lines, I'd like to propose an extension for per-client
I agree with Marius: I think we should keep the explicit flow name in
there (in the 'type' parameter or equivalent), as it (among other
things) opens the possibility for the rescope and revoke operations. It
makes it very clear how both client and server expect things to behave.
-- Justin
On
client authentication (client secret).
EHL
-Original Message-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, June 17, 2010 11:05 AM
To: Marius Scurtescu
Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Proposal: simplification of the end-user
I am working on -09 which I hope will be the last major revision of
the specification. If you were planning on submitting any feedback on
draft -08 or the simplification proposal from David and me, please do
so by tomorrow to be included in the next draft.
I am mostly looking for the
Aside/my $.02: This is a key issue which Salmon+Magic Signatures
evades by essentially treating the HTTP request (the method, URL,
headers, etc.) as advisory/transport hints, to be ignored when reading
the data, and making sure the protocol works even if the data is sent
via carrier pigeon;
I recall there being consensus on the space delimiter to make it so that
URIs could be used easily as scope parameters. I know that I,
personally, would rather have keywords in our implementation than URIs,
so I'm very much in favor of keeping it unspecified.
-- justin
On Thu, 2010-06-24 at
I don't agree: these values are still opaque to OAuth. They're not
opaque to the client and server, they're part of the API. But the client
-- and by client here I mean the whole client application, not just
the OAuth client -- needs to know what they're for. In the same fashion,
the client needs
In most instances outside of the Big Web Companies, OAuth is going to be
the new kid being grafted onto an existing framework or application. As
such, it really needs to play nice.
Just a side note, with extensions also being simple names added to the
protocol chances of a collision with
An easy fix here is to use oauth2_token instead of oauth_token here,
since that's the only place we seem to be using the oauth_ namespace
now. Makes figuring out the two completely deterministic since it's a
different parameter name when passed as a GET or POST variable, and a
different header
OAuth tokens as a form-encoded element in a post body? Yes. Keep it.
-- Justin
On Thu, 2010-07-01 at 14:47 -0400, Marius Scurtescu wrote:
On Thu, Jul 1, 2010 at 11:42 AM, William Mills wmi...@yahoo-inc.com wrote:
-Original Message-
From: Marius Scurtescu
OAuth tokens as a form-encoded element in a post body? Yes. Keep it.
Just curious. What use case would require that the access token is put
in the post body as opposed to an http header when accessing a
protected resource?
If nothing else, it parallels the use case of a GET-style query
+1 on reference to section 2. Also, in 4.1.1, the wording in the last
paragraph makes it sound like the client_secret is REQUIRED for flows
using the authorization code, when as per section 2 the secret is only
required IF a secret was issued with the client_id. Wording such as
found in 4.1.2 is a
Would it help if the client_ stuff were dropped from the example in the
assertion flow? I'm in favor of it being allowed, but if the general use
case is going to be without it then the example should reflect that and
cut down on the confusion.
-- Justin
On Wed, 2010-07-07 at 18:01 -0400, Brian
D
On Thu, 2010-07-08 at 12:29 -0400, David Recordon wrote:
I'm honestly trying to decide myself and a few other people are in
similar situations. Thus a poll:
A) Yes, I'm going to be in Maastricht
B) Maybe, depends on the number of OAuth WG members going
C) Maybe, depends on some other
I'd like to keep form-encoded inputs. I think it makes sense to use a
well-established key-value mechanism, and the asymmetry at play here is
what the web is made of (post a form, get HTML/XML/JSON/whatever).
Along those lines, I'd actually like to relax the restriction of using
POST and allow
+1 on OAuth2 header, and I also want to see oauth2_token in URI and form
parameter methods.
1.0 clients will talk to systems that support both oauth2 and oauth1
simultaneously. Most likely on the same PR endpoints as well. Since the
protocols are not backwards compatible, they should be able to
2.0 just has oauth_token.
--David
On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton bea...@google.com
wrote:
On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer
jric...@mitre.org wrote:
+1 on OAuth2 header, and I also want to see oauth2_token in
URI and form
before. An OAuth 1.0
protected resource request includes a variety of oauth_ parameters
whereas OAuth 2.0 just has oauth_token.
--David
On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton bea...@google.com
wrote:
On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer
jric
:
On Jul 15, 2010, at 10:51 AM, Justin Richer wrote:
It was discussed before, but I don't remember there being any consensus
in the group. What are the practical reasons for not using oauth2
namespacing in the one place we still use namespacing? Most of what I've
heard seems to sound
client_credentials is fine with me for the name of this grant type.
I'd also like the paragraph describing its use to be pulled out into a
subsection, to be parallel with all the other grant types.
-- Justin
On Sat, 2010-07-17 at 15:51 -0400, Eran Hammer-Lahav wrote:
client_credentials worked
Right, Torsten has nailed this use case: it's not tied to unregistered
clients, though they could be useful there, too. We've seen need for
this in both an installed app (actually, a Java Web Start app) and a
server-based email gateway system. In both cases, one user can register
multiple
, Justin Richer jric...@mitre.org wrote:
Right, Torsten has nailed this use case: it's not tied to unregistered
clients, though they could be useful there, too. We've seen need for
this in both an installed app (actually, a Java Web Start app) and a
server-based email gateway system. In both
+2 ;)
I don't like the use of the DELETE method, it feels too much like
overloading the semantics of the HTTP definitions. And as you outline
below, there are a few obstacles on it to make it really workable
anyway.
Another option not laid out below is a parameter on the token endpoint
to
Does the group have an opinion on adding the instance information that I
proposed before* to this UX extension vs. having it live in its own
extension?
-- Justin
* http://www.ietf.org/mail-archive/web/oauth/current/msg03717.html
On Fri, 2010-08-27 at 16:23 -0400, David Recordon wrote:
Given
id than Facebook for Android.
On Fri, Aug 27, 2010 at 8:37 PM, Justin Richer jric...@mitre.org
wrote:
Does the group have an opinion on adding the instance
information that I
proposed before* to this UX extension vs. having it live in
its own
I'm more in favor of this alternative:
[1] http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html
But I can see use cases for both: they basically look at the same
problem from both sides. If Marius would like to bring his draft up to
current spec, I would support its inclusion as a WG
On Mon, 2010-08-30 at 10:53 -0400, David Recordon wrote:
On Mon, Aug 30, 2010 at 7:02 AM, Justin Richer jric...@mitre.org
wrote:
Your first example is the textbook case, actually. You're
still being
asked to authorize TweetDeck, which is identified by its
+1
I've never liked the notion of not being able to extend the grant type
field, and this change addresses that particular gripe.
Just so I'm clear here: an extension that defines its own url-defined
grant type can also legally add and remove parameters from the endpoint,
right?
-- Justin
On
I've looked over this draft, and I don't think a lot of it is necessary
under OAuth2.0. The protected resource no longer has any kind of
client_id associated with it, so a client can take an access token and
hand it off to any other client to use without any other information
needed. To support
Third, I think the implementers guide is absolutely essential.
(Interestingly enough, the discussion of white spaces vs. commas in
yesterday's thread has effectively started this work.) In my opinion,
this item must be carried in parallel with others. I wonder if this
should be tied up
-
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Thursday, September 02, 2010 2:27 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Simpilfying use of assertions when requesting an
access token
+1
I've never liked the notion of not being able
I would like to see the signatures stay in a separate spec, but to be
worked on and released along side of the core spec.
In fact, I think that there's more than one kind of signature that can
be used with the OAuth token mechanisms. At IIW East, we walked through
several use cases that called
If it wasn’t clear, the reason why I am back at fighting for this
after taking a break for a few months, is based on the recent positive
experience from the Twitter migration. To me, it completely voids the
arguments that normalization on the client side is too hard.
I wholeheartedly disagree
I think that any signature method that we end up using needs to rely
less on magic and anecdote and more on explicit declaration.
This is certainly correct ...
I think
that Brian Eaton's approach of sending the bare string that was
signed,
which was also a JSON element that
Perhaps this is picking nits but I want to clarify my opinion: I'm fine
if the core spec *mentions* signatures, I just don't want it to *define*
them. I'm perfectly happy with a section on if you want to do signing,
here's a way to do signing, but I want that way to be defined and
described
Arguments like this are why I have been advocating for separating the
developers guide from the protocol spec for a while now. I believe
that they support two different audiences.
A developers' guide then has the option of combining multiple specs,
selecting profiles of those specs, and laying
I've got XML-based protocols here that we want to protect with OAuth,
and so having to deal with a JSON blob is less than optimal for us. Ages
ago, we decided to make JSON be the One True Encoding for the core spec,
and I commented that I was fine with that if we had a way to represent
things in
: Justin Richer [mailto:jric...@mitre.org]
Sent: Monday, September 27, 2010 12:04 PM
To: Eran Hammer-Lahav
Cc: Dick Hardt; OAuth WG
Subject: Re: [OAUTH-WG] Basic signature support in the core specification
Arguments like this are why I have been advocating for separating
+1 on the split. I think it's an elegant approach, and it won't be any
harder to follow than a monolithic spec with multiple optional sections.
Especially if we put together the right guidance as a gateway to the
spec.
OAuth 1.0 (and -a) really talk about three different things: how to get
a
ch1997 (TXT, HTML, XML).
TOC
6.2.Other References
[google_oauth]
“Google OAuth API Documentation.”
TOC
Author's Address
Justin Richer (editor)
The MITRE Corporation
Network Working Group J. Richer, Ed.
Internet-Draft
...@mitre.org
Subject: New Version Notification for draft-richer-oauth-xml-00
Date: Tue, 9 Nov 2010 09:32:46 -0500
A new version of I-D, draft-richer-oauth-xml-00.txt has been successfully
submitted by Justin Richer and posted to the IETF repository.
Filename: draft-richer-oauth-xml
: Tue, 9 Nov 2010 09:32:37 -0500
A new version of I-D, draft-richer-oauth-instance-00.txt has been
successfully submitted by Justin Richer and posted to the IETF repository.
Filename: draft-richer-oauth-instance
Revision: 00
Title: OAuth Client Instance Extension
I would prefer something like #3, but I think #2 is the most practical
as it keeps the spec mostly hands-off and doesn't put the weight of one
token type above another -- it keeps the kind of token opaque to the
get a token part of the scheme.
#4 is a major fail though.
-- justin
On Thu,
Just as a matter of clarification about the downscope language in the
spec:
The downscoping capability here is intended mostly for getting
special-use tokens, for things like redelegation to other apps. So say I
grant access to AppA with scope read write, and AppA gets a refresh
and access token.
#1
#2 feels like overengineering, and we're going to end up with things
that spit back stuff that aren't token attributes anyway that will want
to put them at the top level.
Also, no need to require a more complex structure. I tried to make it so
that the XML encoding can handle more complex
Is there a real downside to making them both optional with availability
specified by the AS? I have a feeling that's what we're going to end up
with in the wild anyway. That is to say, frameworks that can't dig deep
enough into HTTP to get to the Basic credentials just won't support that
method,
With the core drafts finally settling in, I think it's time for the WG
to look into a widely-used usecase of OAuth 1.0 that's not currently
addressed directly by OAuth2: classical 2-legged OAuth 1.0, or tokenless
signed http fetch.
People use this method today to replace developer key
We need a protocol that does both authentication and
authorization. We can take OAuth and adapt it for
authentication, or take OpenID and adapt it for
authorization, or combine OpenID and OAuth (great solution
for people who love complexity) or... take the best ideas
from OpenID and
2. Section 8.2. What about applications using legacy parameters? Does
not make much sense to register them, and they cannot be changed to
x_.
I *guarantee* that there will be many noncompliant implementations of
this, built on server frameworks with required parameters on all
endpoints. Not
The implicit grant still requires a redirect of some kind, so many
native apps can just as easily use the web server flow as the implicit
flow. I personally don't see how the implicit flow is better suited than
the web flow in this case. However, neither of these are ideally suited
for native
Also, there's a big difference between can keep secrets and can be
packed/shipped with secrets. Many native apps fit into the former
category but not the latter, which makes storage of refresh tokens and
other long-term credentials reasonable, but not server-issued client
secrets.
-- Justin
On
the entire variable set
to figure out what is going on. Now the scheme name determines
things. Now that we have schemes I don't see re-using parameter names
as a problem.
__
From: Justin Richer jric...@mitre.org
Other use cases include the encoding extensions (such as the XML one,
and if anyone gets around to it, the form-encoded one) and a format not
supported error. Having a standard set of oauth errors on the protected
resource is a good idea. That said:
I am still not convinced we need to address
Overall this is in good shape. Some points:
Mutual cross-reference between the MAC and Bearer specs might help
people trying to decide what kind of OAuth token to use.
2.3
The parameter name oauth_token is already taken by OAuth 1.0 and
should NOT be re-used here. Suggest changing it to
Mutual cross-reference between the MAC and Bearer specs might help
people trying to decide what kind of OAuth token to use.
Speaking for MAC - over my dead body :-)
Now now, that's just not nice. :)
___
OAuth mailing list
OAuth@ietf.org
Many of my comments have probably been covered by other folks on the
list, but I'm going to repeat things along here anyway:
Preamble:
Does this document actually obsolete 5849? Since OAuth2 is explicitly
not backwards compatible, is this WG really making the claim that we're
updating OAuth,
I like the organization of the spec with its grant types structure. In
my reading of it, the two endpoints are logical and may be presented
from different URLs and crunched on by several processing engines in the
background. The important thing is the logical distinction between
place where the
What about non-http return uri's, or client-localhost, such as
someapp://app/?code=foo
http://localhost:87345/?code=foo
HTTPS makes sense when you're talking between two web servers, but it
seems to fall apart otherwise. I think SHOULD is appropriate here.
-- Justin
On Fri, 2011-03-25
: Justin Richer [mailto:jric...@mitre.org]
Sent: Monday, March 28, 2011 10:05 AM
To: Eran Hammer-Lahav
Cc: Phil Hunt; OAuth WG
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
What about non-http return uri's, or client-localhost, such as
someapp://app/?code=foo
http
the vendors are going to do (regardless of what
the document says)?
EHL
From: Francisco Corella [mailto:fcore...@pomcor.com]
Sent: Tuesday, March 29, 2011 3:40 PM
To: Phil Hunt; Justin Richer; Eran Hammer-Lahav
Cc: OAuth WG; Karen P. Lewison; Paul Tarjan (p...@fb.com
Better than x_ and still ultimately optional so as to not make server
implementors think that OAuth endpoints must be pristine. In the absence
of having a proper root namespace on this thing (which I'm still bitter
about, I know), this works.
-- Justin
On Tue, 2011-03-29 at 19:13 -0400, Eran
the client identity does not matter (e.g. anonymous client) or
when the client identity is established via other means.
Phil
phil.h...@oracle.com
On 2011-04-04, at 1:09 PM, Justin Richer wrote:
Agreed - we are planning to use the auth-code flow for native apps and
have
While this isn't the original use case I had in mind, this could be
covered by something in the OAuth2 Instance extension:
http://tools.ietf.org/html/draft-richer-oauth-instance-00
-- Justin
On Fri, 2011-04-08 at 12:22 -0400, Phil Hunt wrote:
Why not have the client app generate a random text
Any instance of apache's mod_rewrite will bork up the request URL for
anything behind the rewrite. The server or client code behind a rewrite
will only see the rewritten URL and not the original request URL.
Why not just pack the signed string in with the payload? You would then
have rules on
I would still like to see a binding of this to use query or form
parameters. I have a direct use case for handing out signed URLs to the
client, for which we're using the OAuth 1.0 signing mechanism without
tokens today. I'd love to switch to something that we could bind to
OAuth2, but the
, 2011 at 3:34 PM, Justin Richer jric...@mitre.org wrote:
I would still like to see a binding of this to use query or form parameters.
I have a direct use case for handing out signed URLs to the client, for
which we're using the OAuth 1.0 signing mechanism without tokens today. I'd
love
These could be solved and the whole normalization process thrown out by
just restating the string that you signed. It's then up to the server to
decide if they want to reparse and validate the request or not, but it
gets around url rewriter problems, which I've had definite trouble with
in my
The biggest problem that I can see are the examples and terminology in
the core doc, which tries very hard to not look like it is binding to
any particular use-a-token spec or token format. That plus the history
that George pointed out below (which I still very strongly believe that
'oauth_token'
I couldn't find a conclusion to the May 2010 discussions about using x-www-
form-urlencoded vs. json nor a rationale in the spec for using JSON. Why do
I
need to add a JSON lexer/parser to my library just to get key-value pairs
that
can be represented by form-urlencoded?
Every
On Thu, 2011-06-16 at 04:43 -0400, Tim Brody wrote:
On Wed, 15 Jun 2011 11:45:28 -0400, Justin Richer jric...@mitre.org
wrote:
I couldn't find a conclusion to the May 2010 discussions about using
x-www-
form-urlencoded vs. json nor a rationale in the spec for using JSON.
Why do I
If we're changing the bearer token's name, are we going to change the
parameter name inside of MAC as well? At the moment, it's id, which
I've always found an odd naming choice.
I would argue for consistency across the three main documents.
-- Justin
On Thu, 2011-06-16 at 08:40 -0400, KIHARA,
Agree with Torsten -- I would hate for us to repeat the
anonymous/anonymous thing that Google implemented for OAuth1.
-- Justin
On Thu, 2011-06-16 at 15:42 -0400, Torsten Lodderstedt wrote:
-1 making client authentication required at the access token endpoint
Client authentication is useful
Certainly not. Are we discussing to make client
authentication required just for syntactical purposes?
That is what I'd like to see.
From my perspective, no harm is done by making client authentication
a syntactical requirement of the protocol.
-
The OpenID Connect folks have been using Simple Web Discovery, which is
as I understand it a rough translation of XRD into JSON, with a couple
of simplifying changes. (Mike, want to throw your hat in on this one?)
http://tools.ietf.org/html/draft-jones-simple-web-discovery-00
-- Justin
On Mon,
You can still use the access code (web server) flow within a JavaScript
application, just without a reliable client secret. The point of the
implicit flow was to save a roundtrip to the server for light clients
with limited lifespans, and it's a tradeoff between security, ease of
implementation,
- give out authorization codes via the user-agent flow. We've
implemented a variation of this based on HTML5 and window.postMessage.
Caveat: This will run you off-spec.
- use a fixed callback URL for the user-agent flow. Make sure that
fixed callback URL does not run random bits of
I'm not sure normative language even fits here. We need something like
Authorization codes should be treated as sensitive and the client needs
to try to make sure it doesn't leak the authorization code. But more
formal and less garden pathy than I'm able to pen at the moment.
-- Justin
On
I would avoid using the term open here as it has other deep-seated
meanings in the software world, particularly with regard to Open Source
and Open Standard stuff. FWIW, I think confidential/public or
private/public are serviceable.
-- Justin
On Mon, 2011-07-25 at 02:45 -0400, Eran Hammer-Lahav
In addition to taking another read through the document myself, I asked
another developer here to give it a once over. She's never implemented
an OAuth client or server, but has knowledge of what it's for. Thus, an
experienced developer new to building with OAuth2 -- a key target
audience for
.
-- Justin Richer
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
evaluate
the compatibility of the normalized request string with their
own security requirements.
-- Justin Richer
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Comments inline.
On Wed, 2011-08-17 at 14:15 -0400, Eran Hammer-Lahav wrote:
Thanks for the feedback.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Justin Richer
Sent: Thursday, August 11, 2011 2:07 PM
1.2/1.4: The term
1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Token,
Refresh Token
Not sure. What do others think? I put access token first because it is a
more important term to get out of the way.
I would rather consider to change order to Access Token, Refresh Token,
You can actually issue a JWT as an access token (since OAuth doesn't
care about the token format), so in this case the JWT would be used to
get access to the widget provider. The JWT would be a pre-signed bearer
token that the provider would know how to check.
-- Justin
On 9/2/2011 6:50 PM,
Mike,
The basic argument here is that if the app wants to do bad things, and
you go through the process of authorizing it, it's going to be able to
do bad things. Not just to your stolen credentials, either, since it's
now got an access token too.
OAuth's trust model does work with installed
Mike,
I think this is a red herring. as this vector has nothing to do with
mobile apps. The attack that you've suggested is also possible with a
compromised browser on a desktop using the web flow. In this case, the
browser (UA) can steal the user's credentials and hand them to whoever
they want
+1, this wording is much clearer to me, too
-- justin
On Tue, 2011-09-13 at 19:25 -0400, Greg Brail wrote:
This part of section 1.1 is confusing to me and I stumble whenever I
read it – I see that Brian Eaton suggested looking at it a while back
but I don’t think it got changed:
+1
I would also prefer to not restrict scope values but provide clear
encoding for places where transport is going to be an issue. This is
what we do with tokens, which show up in the same places. Am I missing
the reason we can't use the exact same rules (modulo the single space
character) that
+1
Leave the current text as is, keep this part of OAuth token-type
agnostic.
-- Justin
On Wed, 2011-11-02 at 13:18 -0700, Phil Hunt wrote:
+1
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2011-11-02, at 1:06 PM, John Bradley wrote:
+1
Please clarify what you're asking, if you would: There are two kinds of
authentication which happen with OAuth: client authentication and user
authentication, and neither of which are standardized on two-way TLS.
Client authentication happens at the token endpoint and is described in
section
1 - 100 of 886 matches
Mail list logo
