> 5) Section 3 ABNF allows "realm=foo;realm=bar;scope=baz;error=123"
> is that ok? Is processing clear for all cases? I don't think it
> is.
The ABNF does not allow that.
It requires commas as separators, not semi-colons.
It requires double quotes around values.
The only possible ambiguity in thi
I actually think the protected resource specifies the token type(s) in either
it's service docs or discovery information, and it does know knowing it's
authentication server will issue compatible tokens. The client may encounter
endpoints requiring token types it doesn't support, and it needs t
Eran's point about the definition of a client is an important one.
There are two breeds of OAuth clients: (1) general purpose and (2)
purpose-built for a specific OAuth service.
When discussing interop, something to consider about OAuth is that
discovery is not part of the core spec, which IMHO le
If it's already reported, my apologies.
In section 8.4, "If a response type contains one of more space characters".
It should be "one or more".
Thanks
--
nov matake
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Hi Andre,
how do you think differs the threat you descibed from
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.4.1.4?
regards,
Torsten.
Am 26.10.2011 22:44, schrieb André DeMarre:
Should a brief explanation of this be added to the Threat Model and
Security Considerati
That probably depends on what authentication you are asking about.
Authentication of the client to the protected resource has two profiles MAC &
Bearer.
Authentication of the client to the Token Endpoint has an example in the OAuth
spec using client_id and a symmetric secret.
That is extensible
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 2.3,
I could probably live with the client needing to support both token types if we
quite narrowly define client as a general purpose library designed to support
multiple protocols using OAuth for authorization.
That however is not the general use of the term in OAuth 2.0.
Many clients will be op
What are some common or suggested authentication methods that are used in
conjunction with OAuth 2.0?
Is TLS/SSL the only standard one or do people normally roll their own
authentication within OAuth's flows?
Elliot Cameron
Covenant Eyes Software Developer
elliot.came...@covenanteyes.com
The problem is centered on the definition of a client. If it is a service
specific implementation which is merely using OAuth for access, there isn't any
interop requirements other than making sure the client and server are
compatible. But if the client is a general purpose OAuth library or gene
If we must define a mandatory token type then bearer + TLS would be my
suggestion.
regards,
Torsten.
Am 02.11.2011 21:28, schrieb Stephen Farrell:
Hi Torsten,
On 11/02/2011 07:45 PM, Torsten Lodderstedt wrote:
Hi Stephen,
I'm concerned about your proposal (7) to make support for MAC a MUST
So perhaps this is the interesting point of difference.
On 11/02/2011 08:37 PM, John Bradley wrote:
It is up to the server to decide what formats it will support.
With IETF protocols, its IETF consensus that decides this in
almost all cases that affect interop and it is therefore not
up to th
The issue is that the service provider will likely only accept ONE token format
in practice. The security requirements of the scenario dictate choice of Mac or
bearer or for that matter any other new scheme.
An MTI would complicate the spec by implying a choice of tokens by the client
because
If the spec requires clients to implement both, the reality is most clients
will only impliment one and be non compliant.
Given that openID Connect supports Bearer ONLY. Requiring clients to support
MAC would cause clients to implement code that won't be used.
It is up to the server to decide
Agnostic sounds like a fine word.
I'd need to have it demonstrated to me that it doesn't
mean non-interoperable in this case.
S.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
+1
The predominant industry practice is the use of Bearer tokens, so if either of
Bearer or MAC becomes Mandatory to Implement, it must be the Bearer spec, with
MAC being optional.
I'm fine either remaining silent on this point (leaving the spec token type
agnostic, as Justin suggests), or mak
Hi Torsten,
On 11/02/2011 07:45 PM, Torsten Lodderstedt wrote:
Hi Stephen,
I'm concerned about your proposal (7) to make support for MAC a MUST for
clients and BEARER a MAY only. In my opinion, this does not reflect the
group's consensus.
That wasn't quite my comment, which is below:
(7)
+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
+1
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2011-11-02, at 1:06 PM, John Bradley wrote:
> +1
> On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote:
>
>> Hi Stephen,
>>
>> I'm concerned about your proposal (7) to make support for MAC a MUST for
>> clients and BEA
Do you want to see no change or adjust it to client must implement both, server
decides which to use.
EHL
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of John Bradley
[ve7...@ve7jtb.com]
Sent: Wednesday, November 02, 2011 1:06 PM
To: Torsten L
+1
On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote:
> Hi Stephen,
>
> I'm concerned about your proposal (7) to make support for MAC a MUST for
> clients and BEARER a MAY only. In my opinion, this does not reflect the
> group's consensus. Beside this, the security threat analysis justifies
In the general OAuth case the user doesn't have much incentive to modify the
request parameters.
In Connect the user is also authenticating to the client. There may be cases
where the user attempts to modify the request to escalate privileges.
I suspect state might be something someone would l
Hi Stephen,
I'm concerned about your proposal (7) to make support for MAC a MUST for
clients and BEARER a MAY only. In my opinion, this does not reflect the
group's consensus. Beside this, the security threat analysis justifies
usage of BEARER for nearly all use cases as long as HTTPS (incl. s
Hi,
standard OAuth does not sign request parameters. Does this mean OAuth
itself is not secure enough? Or is there a new threat angle against
those parameters in the contect of Connect?
regards,
Torsten.
Am 27.10.2011 22:24, schrieb George Fletcher:
The main reason to include the OAuth param
On 2011-11-02 17:45, Stephen Farrell wrote:
...
4) What is the realm attribute in section 3? What is a
client expected to do with that? I guess it has to be different
from how realm is used with e.g. Basic. (That might be my
ignorance of HTTP details though;-)
...
Is it different? If it is, it
I have not seen any responses to these items so I assume the group is in
agreement with the comments made. I will push out a revised ID addressing these
items in a few days.
EHL
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Stephen
Hi,
Good work - another one almost out the door! Thanks.
However, I think this one needs a revised ID before we start
IETF LC. Nothing hard to change I hope, but I think there
are enough changes to make that its best done that way.
I reckon items 3,5,7-11 and 13 below need fixing, but are
I ho
27 matches
Mail list logo
