+1
Am 25.07.2011 02:16, schrieb Eran Hammer-Lahav:
How about, add this to 10.1:
When client authentication is not possible, the
authorization server SHOULD employ other
means to validate the client's identity. For example, by
requiring the registration of
th
How about, add this to 10.1:
When client authentication is not possible, the authorization server
SHOULD employ other
means to validate the client's identity. For example, by requiring
the registration of
the client redirection URI or enlisting the resource owner to
Hi,
I just remembered the original aim of the text. We not just intended to list
alternative means but to get a general message across: If you cannot
authenticate a client considers this in your security design! Either (1) you
accept the fact the respective identities can be forged and handle t
Hey Torsten,
The provided text and alternative text are just not helpful. If I am unable to
understand it, I have doubt other readers will be able to.
I don't know what you mean by 'other means' which are not already described in
the document (based on -17). Referencing the security thread mode
seems you are contradicting yourself.
You criticised the MUST and suggested to include some examples. I bought into
your argument and suggested to refer to the security doc for examples and
additional explanations. That's what this document is intended for, to provide
background beyond what we
I still don’t find it useful. I think the existing text overall makes this
point already.
EHL
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, July 06, 2011 12:48 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: Re: Section 10.1 (Client authentication)
Hi Eran,
I would su
Hi Eran,
I would suggest to change it to SHOULD and add a reference to
https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections 3.7 and
5.2.3.
regards,
Torsten.
Eran Hammer-Lahav schrieb:
It's a pointless MUST given how undefined the requirements are. It will only be
unders
It's a pointless MUST given how undefined the requirements are. It will only be
understood by security experts and they don't really need it. At a minimum, it
needs some examples.
EHL
From: Torsten Lodderstedt
mailto:tors...@lodderstedt.net>>
Date: Wed, 1 Jun 2011 00:53:37 -0700
To: Eran Hamme
Hi Eran,
would you please add the following sentence (which was contained in the
original security considerations text) to the second paragraph of
section 1.0.1?
Alternatively, authorization servers MUST utilize
other means than client authentication to achieve their security
objectives
