I agree with what John wrote below. Besides, PoP is more natural to say than
HoK and certainly more natural to say than HOTK. I'd like us to stay with the
term Proof-of-Possession (PoP).
-- Mike
From: OAuth [mailto:oauth-boun...@ietf
Some people and specs associate holder of key with asymmetric keys. Proof of
possession is thought to be a broader category including symmetric and key
agreement eg http://tools.ietf.org/html/rfc2875.
NIST defines the term PoP Protocol
http://fismapedia.org/index.php?title=Term:Proof_of_Posses
What was wrong with HOK?
Aside: Why was “the” so important in HOTK?
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Apr 3, 2014, at 9:37 AM, Anil Saldhana wrote:
> Prateek,
> why not just use "proof"?
>
> draft-hunt-oauth-proof-architecture-00.txt
>
> Is that allowed by
Prateek,
why not just use "proof"?
draft-hunt-oauth-proof-architecture-00.txt
Is that allowed by IETF?
Regards,
Anil
On 04/03/2014 11:30 AM, Prateek Mishra wrote:
"key confirmed" or "key confirmation" is another term that is widely
used for these use-cases
I really *like* the name "proof o
"key confirmed" or "key confirmation" is another term that is widely
used for these use-cases
I really *like* the name "proof of possession", but I think the
acronym PoP is going to be confused with POP. HOTK has the advantage
of not being a homonym for aything else. What about "Possession Proo
I think there are two broad cases to consider:
1. Assuming each client “instance” gets its own client_id (e.g. via Dyn Reg),
my concern about changing client_id is you loose track of the client software’s
relation to the user. In many cases it is more important to track the software
and its rel
This is the question I had. The spec says not to share refresh tokens
across clients, so it all depends on whether or not you consider a new
version a new client. I've usually seen client_id stay the same across
versions, since it's considered "the same client", but you could easily
consider th
Hi Andre,
I would expect the AS to treat a client with a different client id as another
client. So the new client should not be able to use the "old" refresh tokens.
Some further questions/remarks:
- if you utilize refresh tokens, access tokens should be transient. Right? So
you don't need to b
Hi all,
as discussed during the last IETF meeting we are re-factoring our
documents on proof-of-possession. (As a reminder, here is the
presentation I have during the OAuth meeting:
http://www.ietf.org/proceedings/89/slides/slides-89-oauth-0.pptx)*
Mike had already posted draft-jones-oauth-proof-
