Bound Token - Revision history

Tom: /* Solution */

2019-12-18T21:33:02Z

‎Solution

2019-12-18T21:32:17Z

‎Solution

2019-10-22T18:35:01Z

‎Structure

2018-11-06T16:54:14Z

‎User Cases

2018-11-05T21:14:28Z

‎Google Instance Identity

2018-11-05T21:12:33Z

‎Google Instance Identity

2018-11-05T21:01:55Z

‎Solution

2018-10-24T19:58:40Z

‎Structure

2018-10-24T19:53:55Z

‎Solution

2018-10-24T19:51:58Z

‎Context

@@ Line 23: / Line 23: @@
 ==Solution==
 *While there are other solutions to the vulnerabilities of the [[Bearer Token]] (e.g. [[Token Binding]]. This solution is proposed as a simpler, cleaner solution.
-*Since this solution was proposed the [[]] has been described, but not defined in any canonical manner.
+*Since this solution was proposed the [[Sender Constrained Token]] has been described, but not defined in any canonical manner.
 *This wiki page creates a new type of structure to address the problems noted above. It is currently just a draft proposal to get the conversation about the complete solution started.
 ===Structure===

@@ Line 23: / Line 23: @@
 ==Solution==
 *While there are other solutions to the vulnerabilities of the [[Bearer Token]] (e.g. [[Token Binding]]. This solution is proposed as a simpler, cleaner solution.
 *This wiki page creates a new type of structure to address the problems noted above. It is currently just a draft proposal to get the conversation about the complete solution started.
 ===Structure===

@@ Line 26: / Line 26: @@
 ===Structure===
 Unlike the [[Bearer Token]], this proposal is for a structured token that carries binding with it. It is expected that the following will apply:
-# JWT - preferably (or mandatory?) JWS signed by the issuer
+# [[JWT]] - preferably (or mandatory?) JWS signed by the issuer
-# JOSE - whenever private information is included in the token it must be encrypted with the public key of the receiver (aka the aud).
+# [[JOSE]] - whenever private information is included in the token it must be encrypted with the public key of the receiver (aka the aud).
 ===Identifier===

@@ Line 9: / Line 9: @@
 ===User Cases===
-*A user want to allow a [[Web Site]] to access some [[Resource]] (often data, or even [[User Private Information]]) that they own (or control access). The [[Web Site]] (call the [[Client]] in [[OAuth 2.0]]) needs to prove to an [[Authorization Server]] that they have [[User Consent]] to acquire an [[Access Code]] from the [[Authorization Server]]. Then that service will provide the [[Client]] with the [[Access Code]]. In cases where the [[Resource]] is a high value target (e.g. a bank account) the [[Resource Server]] demands more security than that offered by a [[Bearer Token]].
+*A user want to allow a [[Web Site]] to access some [[Resource]] (often data, or even [[User Private Information]]) that they own (or control access). The [[Web Site]] (called the [[Client]] in [[OAuth 2.0]]) needs to prove to an [[Authorization Server]] that they have [[User Consent]] to acquire an [[Access Code]] from the [[Authorization Server]]. Then that service will provide the [[Client]] with the [[Access Code]]. In cases where the [[Resource]] is a high value target (e.g. a bank account) the [[Resource Server]] demands more security than that offered by a [[Bearer Token]].
 ==Problem==

@@ Line 60: / Line 60: @@
+}
 </pre>
 ==Reference==

@@ Line 36: / Line 36: @@
 ===Google Instance Identity===
 https://cloud.google.com/compute/docs/instances/verifying-instance-identity
 ==Reference==

← Older revision		Revision as of 21:01, 5 November 2018
Line 33:		Line 33:

	Note that the most important attribute of a TID that offers up metadata is a URL pointing to the authority. But in the case of a native app, the URL might need to be somewhere else to be useful. Of course such a url could include fragment or sub-directory components that identified the particular instance of the app.		Note that the most important attribute of a TID that offers up metadata is a URL pointing to the authority. But in the case of a native app, the URL might need to be somewhere else to be useful. Of course such a url could include fragment or sub-directory components that identified the particular instance of the app.
		+
		+	===Google Instance Identity===
		+	https://cloud.google.com/compute/docs/instances/verifying-instance-identity

	==Reference==		==Reference==

← Older revision		Revision as of 19:51, 24 October 2018
Line 7:		Line 7:

	The [[Bound Token]] is specifically designed to overcome several of the problems of a [[Bearer Token]].		The [[Bound Token]] is specifically designed to overcome several of the problems of a [[Bearer Token]].
		+
		+	===User Cases===
		+	*A user want to allow a [[Web Site]] to access some [[Resource]] (often data, or even [[User Private Information]]) that they own (or control access). The [[Web Site]] (call the [[Client]] in [[OAuth 2.0]]) needs to prove to an [[Authorization Server]] that they have [[User Consent]] to acquire an [[Access Code]] from the [[Authorization Server]]. Then that service will provide the [[Client]] with the [[Access Code]]. In cases where the [[Resource]] is a high value target (e.g. a bank account) the [[Resource Server]] demands more security than that offered by a [[Bearer Token]].

	==Problem==		==Problem==