Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt

From: Ludwig Seitz <[email-masked]>
Date: Mon, 26 Nov 2018 10:27:09 +0100

Hello ACE,

I have just submitted new versions for draft-ietf-ace-oauth-authz and 
draft-ietf-ace-oauth-params addressing the WGLC review comments and the 
discussions from the IETF 103 meeting.

I would encourage the reviewers to check if they feel that I have 
sufficiently addressed their comments.

Regards,

Ludwig

-------- Forwarded Message --------

A new version of I-D, draft-ietf-ace-oauth-authz-17.txt
has been successfully submitted by Ludwig Seitz and posted to the
IETF repository.

Name:		draft-ietf-ace-oauth-authz
Revision:	17
Title:		Authentication and Authorization for Constrained Environments 
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)
Document date:	2018-11-26
Group:		ace
Pages:		74
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-17.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-17
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-17

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 CoAP, thus making a well-known and widely used
    authorization solution suitable for IoT devices.  Existing
    specifications are used where possible, but where the constraints of
    IoT devices require it, extensions are added and profiles are
    defined.

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

-------- Forwarded Message --------

A new version of I-D, draft-ietf-ace-oauth-params-01.txt
has been successfully submitted by Ludwig Seitz and posted to the
IETF repository.

Name:		draft-ietf-ace-oauth-params
Revision:	01
Title:		Additional OAuth Parameters for Authorization in Constrained 
Environments (ACE)
Document date:	2018-11-26
Group:		ace
Pages:		14
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-params-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-01

Abstract:
    This specification defines new parameters for the OAuth 2.0 token and
    introspection endpoints when used with framework for authentication
    and authorization for constrained environments (ACE).  These are used
    to express the desired audience of a requested access token, the
    desired proof-of-possession key, the proof-of-possession key that the
    AS has selected, and the key the RS should use to authenticate to the
    client.

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

---

From: Jim Schaad <[email-masked]>
Date: Wed, 28 Nov 2018 09:06:07 -0800

Ludwig,

It looks good.  A couple of additional things that have occurred to me.
(Always a problem when on reads drafts again and again.)

1.  I don't really have a problem with figure 6, but I don't know if we want
to more correctly reflect what an OSCORE message would look like in this
location.  This would basically be a re-write of the entire example
structure to reflect that you have an outer and an inner CoAP message.  It
might be confusing for people who are not fully immersed in the OSCORE
world.

2.  I have no idea of where this would go and it is perhaps something that
the OAuth people need to think about as well.  If an AS receives a request
which has message level security (OSCORE/CWT/JWT) over a session level
security connection (TLS/DTLS/IPSEC) are there any rules/suggestions about
which keys should be used for evaluating the resulting request.  While I
assume that message security wins and the session security is ignored, I
have not seen this anyplace.

3. In section 5.8.1 - It says that for a CWT access token that the
application/cwt content type MUST be used.  There are two possible issues
with this.  1) How does the client know what the type of the token is.  It
could be a CWT, an introspection token, or something else entirely.  2)  Is
it an error if a CWT token is received and the content type is not present?

Jim

> -----Original Message-----
> From: Ace <[email-masked]> On Behalf Of Ludwig Seitz
> Sent: Monday, November 26, 2018 1:27 AM
> To: [email-masked]
> Subject: [Ace] Fwd: New Version Notification for
draft-ietf-ace-oauth-authz-
> 17.txt and draft-ietf-ace-oauth-params-01.txt
> 
> Hello ACE,
> 
draft-ietf-
> ace-oauth-params addressing the WGLC review comments and the discussions
> from the IETF 103 meeting.
> 
sufficiently
> addressed their comments.
> 
> 
> Regards,
> 
> Ludwig
> 
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace