FYI
-Original Message-
From: apps-discuss-boun...@ietf.org
[mailto:apps-discuss-boun...@ietf.org] On Behalf Of ext Mark Nottingham
Sent: Thursday, November 24, 2011 8:22 AM
To: IETF Apps Discuss; draft-ietf-oauth-v2-bearer@ietf.org
Cc: The IESG
Subject: [apps-discuss] APPS Area review
Eran,
I see value (at least for servers) in having browser and HTTP clients work with
common tokens (e.g. MAC) - even though the mechanism for exchange may vary.
I had an email exchange with Harry Halpin. He suggests cross posting to the w3c
public-identity list.
They are discussing web crypto
-Original Message-
From: apps-discuss-boun...@ietf.org [mailto:apps-discuss-boun...@ietf.org] On
Behalf Of Mark Nottingham
Sent: Wednesday, November 23, 2011 10:22 PM
To: IETF Apps Discuss; draft-ietf-oauth-v2-bearer@ietf.org
Cc: The IESG
Subject: [apps-discuss] APPS Area review of d
With only three characters combinations are at a premium.
People can all ways use longer names.
The ones that are going to be in most tokens are the important ones to keep
short and memorable.
tid seems clearer than jti, but that is just me. I will go with whatever is
decided.
John B
Sen
Thinking about it a bit more, since others may want to use "tid" for claims
with meanings like Transaction ID ( or other words beginning with "t"), maybe
the claim name should be "jti" (JSON web Token ID) to reduce chance of name
collisions?
Thanks John. This makes sense to me.
Feedback from others?
-- Mike
From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Wednesday, November 23, 2011 5:02 PM
To: oauth WG
Cc: Mike Jones
Subject: Message ID for draft-jones-oauth-jwt-beare
The draft-jones-oauth-jwt-bearer profile is lacking a message ID that exists in
the SAML version.
This is important for the receiver to detect replay attacks.
For Connect I made up a claim to use:
tid The tid (token id) claim, A nonce or unique identifier for the assertion.
The Assertion ID m
No objection from me, but it's too bad the browser vendors aren't interested.
-Peter
On Sat, Nov 19, 2011 at 10:33 AM, Eran Hammer-Lahav wrote:
> I would like to drop the cookies support defined in the MAC document due to
> lack of interest from the browser vendors. At this point it is most like
As long as a specific service can make an ext containing the body hash
required, I think this is fine. Can the spec include body hash as an
example of an ext?
Thanks,
Peter
On Sat, Nov 19, 2011 at 10:39 AM, Eran Hammer-Lahav wrote:
> I want to reaffirm our previous consensus to drop the body-h
