Re: [OAUTH-WG] AD review of draft-ietf-oauth-amr-values

Thanks, Mike. I'll look at the shepherd report and see if it is ready to start last call. Best regards, Kathleen On Mon, Nov 14, 2016 at 2:29 AM, Mike Jones wrote: > Thanks for your review, Kathleen. Draft -04 has been published to address > these comments.

Re: [OAUTH-WG] AD review of draft-ietf-oauth-amr-values

Thanks for your review, Kathleen. Draft -04 has been published to address these comments. Actions taken are described inline. -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kathleen Moriarty Sent: Saturday, October 29,

[OAUTH-WG] “amr” Values specification addressing area director comments

Draft -04 of the Authentication Method Reference Values specification addresses comments by our security area director Kathleen Moriarty. Changes were: · Added “amr” claim examples with both single and multiple values. · Clarified that the actual credentials referenced are not part

[OAUTH-WG] I-D Action: draft-ietf-oauth-amr-values-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : Authentication Method Reference Values Authors : Michael B. Jones Phil Hunt

[OAUTH-WG] Draft OAuth WG meeting minutes for 9:30-noon 14-Nov-16 in Seoul

Hannes gave an OAuth WG status update AMR Values spec sent to the IESG Request by JWS spec sent to the IESG Native apps specification Recently updated to make it more readable Hannes is working on a

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

Right — this is a fine way to put it. RFC7591 defines a client model where RFC6749 didn’t. Ideally all that metadata would’ve been in the original spec, but it’s not. It doesn’t matter whether the client was registered dynamically or statically, it just matters that the AS knows what to expect

Re: [OAUTH-WG] OAuth: the ABC attack (the Alice and Bob Collusion attack)

Nat and Torsten, My responses ares embedded in your text. I agree, we should analyse the threat. From my first impression it feels like injection with some specialties. Not exactly. In most scenario attacks, we have two good guys (Alice and Bob) and one bad guy (Carol) acting as the single

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

Yes, the intend is that the authentication method is determined by client policy regardless of whether the client was dynamically registered or statically configured or whatever. I can make that point more explicit in future revisions of the draft. On Sat, Nov 12, 2016 at 10:59 PM, Torsten

[OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 for Native Apps Authors : William Denniss John Bradley

[OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-topics-00.txt

Hi all, I just uploaded the first version of a security document we have been talking about since Berlin. It is intended to be a tool to help us to systematically address all open topics re OAuth security. I will present the draft in the meeting on Wednesday. I would like to ask anybody to

[OAUTH-WG] Milestones changed for oauth WG

Changed milestone "Submit 'Request by JWS ver.1.0 for OAuth 2.0' to the IESG for consideration as a Proposed Standard", resolved as "Done". Changed milestone "Submit 'Authentication Method Reference Values' to the IESG", resolved as "Done". URL: https://datatracker.ietf.org/wg/oauth/charter/

Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00

For example scim has many resources. But it is reasonable to discover at its root since clients may ask for other resources. The as would not likely change across a single scim provider. Phil > On Nov 13, 2016, at 5:27 PM, Torsten Lodderstedt > wrote: > > I see

Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00

I see your point but do you really think this is needed and efficient enough for practical use? Basing metadata handling on single resources (distinct URLs including different query parameters, right?) in my opinion means: - the client needs to discovery the AS for every of those URLs - the

Re: [OAUTH-WG] Using Referred Token Binding ID for Token Binding of Access Tokens

thanks. So the underlying implementation is supposed to create the signed data (TokenBindingMessage) and the client (or library) is supposed to create the header? Am 13.11.2016 um 15:43 schrieb Mike Jones: The HTTP header is described in