Identity/CryptoIdeas/03-ID-Attached-Data: Difference between revisions

Identity/CryptoIdeas/03-ID-Attached-Data (view source)

661 bytes added , 21 February 2013

Confirmed users

471

edits

@@ Line 190: / Line 190: @@
 discussion.. it seems like a useful feature, but obviously allows IdPs to
 clobber data they cannot read, which could be surprising.
+If the server is eager to be RESTful and needs a distinct per-user identifier
+to go into the URL for the Read() and Write() APIs, the best choice is to use
+a hash of the token. This can be safe (even if we assume that URLs are not
+secret) because tokens are derived from full-entropy keys, and thus not
+vulnerable to dictionary attacks. When the token is set with UpdateToken(),
+the server can compute the UID and record it in an index. The server must
+check that both the UID and the token match the recorded data. (Less eager
+server designs should just use a common POST URL for all APIs and put the
+one token in the request body, omitting any sort of UID).
 == Revocation ==