Re: [OAUTH-WG] IANA registry for error codes of RFC6749 section 5.2?

On 10/10/2019 17:02, Justin Richer wrote: They are in that registry as the “token endpoint response” error codes. RFC8628 adds new ones. I think that 6749 failed to put in the base ones. — Justin That would explain my confusion. Errata-worthy? /Ludwig -- Ludwig Seitz, PhD Security Lab

[OAUTH-WG] IANA registry for error codes of RFC6749 section 5.2?

e one? Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Question regarding RFC 7800

, Ludwig [1] https://datatracker.ietf.org/group/ace/documents/ -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

: in figure 3 you seem to be using the "jwk" claim to include the pop-key in the token. Any reason for not using the "cnf" claim from RFC 7800? /Ludwig My bad, figure 3 is not a token (although it looks like one) it's the token request (encapsulated in a J

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

https://github.com/webhamster/draft-dpop - Daniel A quick nit: in figure 3 you seem to be using the "jwk" claim to include the pop-key in the token. Any reason for not using the "cnf" claim from RFC 7800? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51

Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

owever the audience claim is defined to be "StringOrURI" so if someone defines an audience identified by a String that is not an URI how does a client ask for that with the resource parameter? Or in short: Why don't you make your resource parameter mirror the "aud" claim?

Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

For example my intent was to use "aud" and "req_aud" for group identifiers ("temperatureSensorGroup4711") and other non-uri strings (hash-of-public-key), which I cannot do with "resource". We therefore decided to keep the "req_aud" parameter in d

Re: [OAUTH-WG] exp claim ... was RE: expires_in

it is important in some usecases that the client no longer uses the pop-key material when the token has expired. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/m

Re: [OAUTH-WG] expires_in

earlier or later). That is my understanding as well, I would however have expected that this parameter would be aligned with the 'exp' claim of the token. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 ___ OAuth ma

Re: [OAUTH-WG] PoP Key Distribution

ore narrow to me (which is why I created 'profile'). If we could extend the definition of 'alg' a bit, I'd be OK to remove 'profile' from the ACE draft (provided the OAuth draft moves forward in a timely manner). /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE

Re: [OAUTH-WG] PoP Key Distribution

so that pre-configuring clients with metadata about the RS is difficult. Do you have a better idea how to solve these cases? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt

group and therefore the target audience of that token. Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE ICT/SICS Phone +46(0)70-349 92 51 smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://

Re: [OAUTH-WG] Future of PoP Work

e future status of the pop drafts would be. I'm absolutely willing to remove the text again and reference an OAuth WG document instead, if I feel it will not significantly delay the progress of the ACE draft. Hope this information helps in the decision making. Regards, Ludwig -- Lud

Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS

nd to the Raw RSA key of C?So RS would never need to be told about C's key, because the AS would have told it "key XYZ can access resource ABC" in the OAuth token. Yes if the PoP token uses a public key as PoP key. C could even generate an ephemeral key-pair just for this token

Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS

are. Is this some work that the WG is planning to do? /Ludwig -- Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelevägen 17 SE-223 70 Lund Phone +46(0)70 349 9251 http://www.sics.se smime.p7s Description: S/MIME Cryptographic Signature

Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS

-- Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelevägen 17 SE-223 70 Lund Phone +46(0)70 349 9251 http://www.sics.se smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https

Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS

Thank you Michael! Comments inline. /Ludwig On 02/04/2016 03:31 PM, Michael Richardson wrote: Ludwig Seitz wrote: > Assuming we are using (D)TLS to secure the connection between C and RS, > assuming further that we are using proof-of-possession tokens [2], > i.e. toke

[OAUTH-WG] Questions about OAuth and DTLS

c PoP keys as client-authentication key as in RFC7250. Regards, Ludwig [1] https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ [2] https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02 -- Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheeleväg