We think the security considerations should be based on a threat model of
OAuth. But a complete threat model would blow up the spec.
We therefore aim to produce a separate security document (informational
I-D/RFC) covering threat model as well as security design and considerations.
The
I would say that the security considerations should be based on a model
of OAuth. Start with a model of the protocol and the guarantees you
want, then explain how to use security mechanisms to achieve those
guarantees.
I promised Hannes today to do a review of the current document (which I
We held a session on naming for JSON Web Tokens (JWTs) at IIW (Wednesday during
Session 5 in space E), building upon the results from the JSON
Tokenshttp://self-issued.info/?p=361 and No Base
Stringhttp://iiw.idcommons.net/No_Base_String sessions on Tuesday and the
JSON Token
XML encoding of JSON output values, for when you want to use OAuth with
an XML API.
It is my intent that this (and the instance draft) become working group
items.
-- Justin
Forwarded Message
From: IETF I-D Submission Tool idsubmiss...@ietf.org
To: Richer, Justin P.
Client instance information - an update on Google's
xoauth_display_name idea.
-- Justin
Forwarded Message
From: IETF I-D Submission Tool idsubmiss...@ietf.org
To: Richer, Justin P. jric...@mitre.org
Subject: New Version Notification for draft-richer-oauth-instance-00
Date:
Hi Mark, Richard, and Torsten,
there is certainly a very good piece of work available to us for getting the
security consideration text pulled together.
We still have to find out how to best tackle the work. We obviously cannot put
an extended version of the current document into the security
The final session at IIW related to JSON Web Tokens (JWTs) explored whether and
how to represent public key information as JWTs or other JSON structures as an
alternative to X.509 certificates. Thanks to Breno de Medeiros for taking
noteshttp://iiw.idcommons.net/JSON_Spec_Work_continued, which
I've now finished my series of posts on the JSON token spec work that occurred
at IIW. For reference, they are:
- JSON Token Spec Results at IIW on Tuesday: http://self-issued.info/?p=361
- JSON Token Encryption Spec Results at IIW on Wednesday:
http://self-issued.info/?p=378
- JSON
Issue here is that guarantees (and what you want as a guarantee may not be what
somebody else wants) can vary depending on scenario and deployment.
-Original Message-
From: Richard L. Barnes [mailto:rbar...@bbn.com]
Sent: Tuesday, November 09, 2010 12:54 AM
To: tors...@lodderstedt.net
Of course not every scenario calls for all of the security knobs to be
turned to 11. Think of things instead in terms of syllogisms: IF you
want X guarantee, THEN you MUST do A, B, C.
Then you can also read the same things backwards in a given deployment
scenario: Given that I can't do B, I
Am 09.11.2010 16:51, schrieb Hannes Tschofenig:
Hi Mark, Richard, and Torsten,
there is certainly a very good piece of work available to us for getting the
security consideration text pulled together.
We still have to find out how to best tackle the work. We obviously cannot put
an extended
(With apologies for bringing up a tangential matter...)
Talking about the OAuth model, I still see here Client instead of
Consumer. I thought there was an agreement on the terminology
change. I have no specific preference for either term, but I think it
is essential that our terminology be
12 matches
Mail list logo
