[Ace] FW: [EXTERNAL] New Version Notification for draft-ietf-ace-oauth-authz-36.txt
Hello ACE, In order to move the discussion forward I decided to implement the changes suggested by Steffi to address the comments raised by John. Thank you for this contribution Steffi. This update also fixes two minor issues found by Francesca (mismatches in datatypes between text and figures, see diff or github for details). /Ludwig -Original Message- From: internet-dra...@ietf.org Sent: den 17 november 2020 08:28 To: Hannes Tschofenig ; Seitz Ludwig ; Goeran Selander ; Erik Wahlstroem ; Samuel Erdtman Subject: [EXTERNAL] New Version Notification for draft-ietf-ace-oauth-authz-36.txt A new version of I-D, draft-ietf-ace-oauth-authz-36.txt has been successfully submitted by Ludwig Seitz and posted to the IETF repository. Name: draft-ietf-ace-oauth-authz Revision: 36 Title: Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Document date: 2020-11-17 Group: ace Pages: 87 URL: https://www.ietf.org/archive/id/draft-ietf-ace-oauth-authz-36.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-36 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-36 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] I-D Action: draft-ietf-ace-oauth-authz-36.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename: draft-ietf-ace-oauth-authz-36.txt Pages : 87 Date: 2020-11-16 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-36 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-36 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-36 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [EXTERNAL] oauth-authz: Introspection endpoint method
Hi Christian, The short answer is: We aligned as close as possible with OAuth 2.0, and there Introspection uses POST. /Ludwig > -Original Message- > From: Christian Amsüss > Sent: den 16 november 2020 08:59 > To: draft-ietf-ace-oauth-au...@ietf.org; draft-tiloca-ace-revoked-token- > notificat...@ietf.org; ace@ietf.org > Subject: [EXTERNAL] oauth-authz: Introspection endpoint method > > Hello ACE-OAuth authors, authors of revoked-token-notifcation, and ACE group > in general, > > while trying to understand the necessity for revoked-token-notification, I was > looking into the introspection parts of ACE > (draft-ietf-ace-oauth-authz-35 Section 5.7.1) and was confused at the method > used there: > > > Given the introspection endpoint is used for querying, why is it using the > POST > method? This indicates that the request may not be safe (in REST terminology), > which seems not the case. > > > This would have the nice properties of indicating its safeness to the rest of > the > stack (ie. the CoAP library can forego request deduplication). Also, it'd > keep the > door open for caching (where obviously `exi` would be inapplicable, but `Max- > Age: ...` would be used instead), and observing a particular introspection > would > be possible. > This sure wouldn't make revoked- obsolete, but I think it'd make the path > there > smoother, and help sharpen what the TRL adds. > > If there's no particular reason to keep POST and it's early enough for such a > change, the change to the document would be minimal, and unless any > implementation is built on a CoAP stack without support for RFC8132, changes > there should be trivial. > > Best regards > Christian > > > Bycatch: The example in figure 13/14, the Uri-Path should probably be in > Figure > 14 instead, along with the inner code (which is suggested to change above). > Given figure 15 is shown as the full protected message, the same format may > work well for a single figure 13/14 as well (with just a note that this is an > encrypted exchange). > > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] oauth-authz: Introspection endpoint method
Hello ACE-OAuth authors, authors of revoked-token-notifcation, and ACE group in general, while trying to understand the necessity for revoked-token-notification, I was looking into the introspection parts of ACE (draft-ietf-ace-oauth-authz-35 Section 5.7.1) and was confused at the method used there: Given the introspection endpoint is used for querying, why is it using the POST method? This indicates that the request may not be safe (in REST terminology), which seems not the case. This would have the nice properties of indicating its safeness to the rest of the stack (ie. the CoAP library can forego request deduplication). Also, it'd keep the door open for caching (where obviously `exi` would be inapplicable, but `Max-Age: ...` would be used instead), and observing a particular introspection would be possible. This sure wouldn't make revoked- obsolete, but I think it'd make the path there smoother, and help sharpen what the TRL adds. If there's no particular reason to keep POST and it's early enough for such a change, the change to the document would be minimal, and unless any implementation is built on a CoAP stack without support for RFC8132, changes there should be trivial. Best regards Christian Bycatch: The example in figure 13/14, the Uri-Path should probably be in Figure 14 instead, along with the inner code (which is suggested to change above). Given figure 15 is shown as the full protected message, the same format may work well for a single figure 13/14 as well (with just a note that this is an encrypted exchange). -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
