Small update to the Introspection draft incorporating comments from the past
couple days. I haven't put together the IANA considerations section that will
tie the introspection claims to the JWT registry yet, but that's the intent.
Please check the diffs, read the new version, and continue to se
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth 2.0 Token Introspection
Author : Justin Richer
Filename: draft-
Quoting from 7.1
"It is RECOMMENDED that the output of a suitable random number generator be
used to create a 32-octet sequence."
So the spec is already recommending 256 bits of randomness, is that language
not clear enough?
On Wednesday, December 3, 2014 3:17 AM, Hannes Tschofenig
wrot
On Dec 3, 2014, at 9:03 AM, Thomas Broyer
mailto:t.bro...@gmail.com>> wrote:
On Tue Dec 02 2014 at 19:53:27 Richer, Justin P.
mailto:jric...@mitre.org>> wrote:
Thomas, thanks for the review. Responses inline.
On Dec 2, 2014, at 11:08 AM, Thomas Broyer
mailto:t.bro...@gmail.com>> wrote:
T
On Tue Dec 02 2014 at 19:53:27 Richer, Justin P. wrote:
> Thomas, thanks for the review. Responses inline.
>
> On Dec 2, 2014, at 11:08 AM, Thomas Broyer wrote:
>
>
> The methods of managing and
>validating these authentication credentials are out of scope of this
>specification, t
Hi all,
I also wanted to respond to various ideas that were entertained,
including adding salt into the hash function and also for including
other parameters in the hash.
Before adding new functionality we have to talk about the threats we are
trying to address.
For example, adding salt just mak
On 12/03/2014 01:14 PM, John Bradley wrote:
> The only question is if the OAuth ext review list is the correct place for
> review.
I think it is.
signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://ww
The only question is if the OAuth ext review list is the correct place for
review.
I don't have a problem with re using an existing review process for a new
registry, if that works for people.
John B.
> On Dec 3, 2014, at 9:09 AM, Hannes Tschofenig
> wrote:
>
> I just looked at the IANA c
I just looked at the IANA consideration section and I noticed that there
is no policy defined for adding, or deprecating values from various
registries, such as the code_challenge_method.
So, you can essentially decide about how easy or difficult you can make
it for yourself.
I would think that '
We have been thinking that new hash functions and new mechanisms (eg ECDH-ES)
would be treated the same and require a spec and review.
(At some point I will do a asymmetric extension so that the key can also be
used to encrypt POP keys back to the client, but I don't want to make this
spec lo
Hi John,
I believe it makes sense to give recommendations for extensions (if you
envision them). Of course, I hope that we do not see a flood of
extensions that all use different hash functions.
Changing the mechanism to something that provides even stronger security
properties would definitely r
Thanks Hannes.
One question: we are recommending 32 octetes=256 bits to fill the sha256
range. Is there a reason for asking for a lesser entropy?
On 2014年12月3日(水) at 20:37 John Bradley wrote:
> Thanks Hannes.
>
> Other methods such as different hashes need to be added via extension
> specs.
>
>
Thanks Hannes.
Other methods such as different hashes need to be added via extension specs.
Are you saying that we should set minimum recommendations for them.
It is also possible that those methods might use something other than hashing.
Key agreement might be a possibility.
Those propert
Hi all,
I am trying to figure out how to progress the SPOP document and
therefore I read through the discussion about the code challenge, see
I wanted to share my view about this topic.
As a summary, the mechanism works as follows:
C: Compute code_verifier:=rand()
C: Compute code_challenge:=fun
14 matches
Mail list logo
