Richard Barnes has entered the following ballot position for
draft-ietf-oauth-jwt-bearer-10: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to htt
Richard Barnes has entered the following ballot position for
draft-ietf-oauth-saml2-bearer-21: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to h
Richard Barnes has entered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to htt
On 10/15/14 6:06 PM, Brian Campbell wrote:
Thanks for your review and feedback, Pete. Replies are inline below...
Thanks for addressing the comments, including Barry's followup. Just on
the questions:
On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick
mailto:presn...@qti.qualcomm.com>> wrote:
Fair point. I'll add some text saying that in the next revision.
On Wed, Oct 15, 2014 at 5:18 PM, Barry Leiba
wrote:
>
>>>Assertions used in the protocol exchanges defined by this
>>>specification MUST always be protected against tampering using a
>>>digital signature or a keyed mess
>
>
>>Assertions used in the protocol exchanges defined by this
>>specification MUST always be protected against tampering using a
>>digital signature or a keyed message digest applied by the issuer.
>>
>> Why is that? Aren't you using assertions over a protected channel (as
>> required
Thanks for your review and feedback, Pete. Replies are inline below...
On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick
wrote:
> Pete Resnick has entered the following ballot position for
> draft-ietf-oauth-assertions-17: No Objection
>
> When responding, please keep the subject line intact and rep
Hi, in our project we ship a transformer implementation that assumes
that a code verifier represents a base64url encoded SHA-256 hash of the
code challenge
Cheers, Sergey
On 15/10/14 19:48, Chuck Mortimore wrote:
We're actually debating it internally. It seems easiest to just encode
the bina
We're actually debating it internally. It seems easiest to just encode
the binary code up front. Any issue with that?
- cmort
On Oct 15, 2014, at 8:32 AM, Nat Sakimura wrote:
Thanks.
So, to be clear, are you base64url encoding when sending it over the wire
or is your code verifier is creat
Thanks.
So, to be clear, are you base64url encoding when sending it over the wire or is
your code verifier is created by base64url encoding the binary value so that
you do not need to encode it when sending it over?
=nat via iPhone
Oct 16, 2014 00:27、Chuck Mortimore のメッセージ:
> We went with
We went with base64url in our implementation
On Tue, Oct 14, 2014 at 2:26 AM, Nat Sakimura wrote:
> In his mail, Mike asked whether code verifier is
> a value that is sendable without trnasformation
> as a http parameter value, or if it needs to be
> % encoded when it is being sent.
>
> We have
Thanks for your review and feedback, Vincent. I'm adding the working group
to the thread so they’re aware of the comments. Replies are inline below...
From: Vincent Roca
> Date: Tue, Oct 14, 2014 at 9:10 AM
> Subject: Secdir review of draft-ietf-oauth-saml2-bearer-21
> To: IESG , sec...@ietf.or
12 matches
Mail list logo
