Oh, sorry - I see point 13. I reference got cut from the mail thread... I got
that impression from the AS Request Creation Hints message. From my review:
13. -----
valid access token. The AS Request Creation Hints message is a CBOR
map, with an OPTIONAL element "AS" specifying an absolute URI (see
FP: another case where CBOR seem mandatory.. Is this the case, even if HTTP or
other protocol is used?
Thank you, that would be useful. Links to mail threads and/or your recalled
summary are much appreciated.
Francesca
On 25/03/2021, 16:36, "Hannes Tschofenig" <hannes.tschofe...@arm.com> wrote:
Hi Francesca,
CBOR is used in different places throughout the document. There are several
different interfaces (C<->AS, C<->RS, RS<->AS and also the token encoding
itself).
For which part does the document give you the impression that CBOR is
mandatory?
Ciao
Hannes
PS: I will dig out discussion with the OAuth group on the issue of PoP
tokens and how to request a PoP token with HTTP over the client-to-AS interface
to then present it via a different transport to the RS.
-----Original Message-----
From: Francesca Palombini <francesca.palomb...@ericsson.com>
Sent: Thursday, March 25, 2021 3:59 PM
To: Cigdem Sengul <cigdem.sen...@gmail.com>; Francesca Palombini
<francesca.palombini=40ericsson....@dmarc.ietf.org>; Hannes Tschofenig
<hannes.tschofe...@arm.com>
Cc: Seitz Ludwig <ludwig.se...@combitech.se>; The IESG <i...@ietf.org>;
ace-cha...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org; ace@ietf.org;
sec-...@ietf.org
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on
draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)
Hi Cigdem,
I just quickly scanned the MQTT profile, and noticed that for example the
C-AS interaction defined in the MQTT-TLS profile (using a new media type
"application/ace+json") do not map with what is currently defined in the ACE
framework (which maps more closely to what OAuth 2.0 does, using
"application/x-www-form-urlencoded" format with a character encoding of UTF-8
in the HTTP request entity-body for example for the C-AS request).
My comment on point 13. is that: right now I read the framework as "it
requires CBOR" for this exchange, and I agree with you this didn't seem to go
with the rest of the specification - I was not requesting CBOR to be made
mandatory, on the contrary I was pointing out an inconsistency within the
document.
To re-iterate: I am ok with keeping a different encoding than CBOR in, but
I do believe it needs clarification in the document. Also I did not suggest to
remove HTTP from the specification.
Hannes - could you please remind me the substance of the discussion and the
motivations for having this flexibility on encoding? Ludwig mentions "to allow
legacy OAuth 2.0 equipment (i.e. not supporting ACE) to be used in ACE
interactions on those legs of the communication where no constrained devices
are involved." I feel like it would not be hard for OAuth2.0 ASes to support
CBOR, they would need to support more processing defined by the Ace framework
anyway.. Again, as I said several times, I am ok with stepping back, I just
wanted to make sure I understood the motivation for a discussion which I
haven't followed closely.
Francesca
On 25/03/2021, 15:10, "Cigdem Sengul" <cigdem.sen...@gmail.com> wrote:
Hello,
I would like to add my two cents to this as the MQTT-TLS profile does
use
HTTP/JSON for client-AS and rs-AS communication as similar already was
supported in MQTT implementations between an MQTT broker and external
servers (e.g., via auth plug-ins).
For points like 13: Making CBOR mandatory would break how it is
implemented
for MQTT-TLS, which implements the AS creation hints as a User Property
inside an MQTT message.
"The User Property is a UTF-8 string pair, composed of a name and a
value.
The name of the User Property MUST be set to
"ace_as_hint". The value of the user property is a UTF-8 encoded
JSON string containing the mandatory "AS" parameter, and the optional
parameters "audience", "kid", "cnonce", and "scope" as defined in
Section 5.1.2 of the ACE framework"
Kind regards,
--Cigdem
On Thu, Mar 25, 2021 at 1:53 PM Francesca Palombini
<francesca.palombini=
40ericsson....@dmarc.ietf.org> wrote:
> Ludwig,
>
> Thank you for the quick reply, and for the useful background
information.
>
> As I said, I think this document is important and should move forward
> asap, and it can do so without changing the main assumptions, with
some
> additional clarifications in the text about CBOR vs "other" when HTTP
is
> used (which in my opinions are necessary - see points 1, 8, 10, 11,
13, 15,
> 17, 22, 23, 26, 28).
>
> What I wanted to highlight is that it would simplify the document a
lot to
> just remove this flexibility, for which I don't understand the
motivation,
> and say "CBOR is mandatory" even when HTTP is used. The flexibility
could
> be added in a future document if needed. However, I understand that
there
> is history in the working group, and I will step back and remove my
DISCUSS
> if I am in the rough. Note however that in terms of work on the
document I
> suspect that keeping this flexibility will require more work, not
less.
>
> Looking forward to discussing this with Ben during the telechat.
> Francesca
>
> On 25/03/2021, 08:50, "iesg on behalf of Seitz Ludwig" <
> iesg-boun...@ietf.org on behalf of ludwig.se...@combitech.se> wrote:
>
> Hello Francesca,
>
> Thank you for your review. I will address your detailed comments
> separately, with regards to your DISCUSS:
>
> The option to allow both HTTP and JSON for any leg of the
> communication (client-AS, rs-AS, client-rs) was the result of long
> discussions in the WG. If I recall correctly the intent was to allow
legacy
> OAuth 2.0 equipment (i.e. not supporting ACE) to be used in ACE
> interactions on those legs of the communication where no constrained
> devices are involved.
> I am reluctant to reopen these discussions at this point in time,
and
> I suspect doing the necessary analysis to provide in-depth
considerations
> on the choices between HTTP/CoAP and JSON/CBOR will significantly
delay the
> progress of this document.
>
> @ace-chairs: What is your suggestion on how to best handle this?
> (Please note that I am unable to commit significant amounts of
time to
> this work in the foreseeable future)
>
> Regards,
>
> Ludwig
>
>
> > -----Original Message-----
> > From: Ace <ace-boun...@ietf.org> On Behalf Of Francesca
Palombini
> via
> > Datatracker
> > Sent: den 24 mars 2021 15:50
> > To: The IESG <i...@ietf.org>
> > Cc: art-...@ietf.org; ace-cha...@ietf.org; draft-ietf-ace-oauth-
> > au...@ietf.org; ace@ietf.org
> > Subject: [EXTERNAL] [Ace] Francesca Palombini's Discuss on
> draft-ietf-ace-
> > oauth-authz-38: (with DISCUSS and COMMENT)
> >
> > Francesca Palombini has entered the following ballot position
for
> > draft-ietf-ace-oauth-authz-38: Discuss
> >
> > When responding, please keep the subject line intact and reply
to
> all email
> > addresses included in the To and CC lines. (Feel free to cut
this
> introductory
> > paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found
here:
> > https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
> >
> >
> >
> >
> ----------------------------------------------------------------------
> > DISCUSS:
> >
> ----------------------------------------------------------------------
> >
> > Thank you for this document. I think this is an important
document
> which
> > should move forward, but I would like to discuss some points
before
> it does
> > so. These might result in simple clarifications, or might
require
> more
> > discussion, but I do hope they help improve the document.
> >
> > General comments:
> >
> > I found confusing to understand how optional or mandatory is
the use
> of
> > CBOR for profiles of this specification compared to the
transport
> used. I
> > understand the need for flexibility, but maybe it should be
> clarified the
> > implication of using CoAP (is CBOR mandatory then?) vs HTTP (is
CBOR
> always
> > permitted? How is the encoding in that case? Is the same media
type
> > application/ace+cbor used in that case?). Note also that while
> requests
> > include the content type to use, both in case HTTP or CoAP+CBOR
are
> used,
> > the response don't seem to include this information.
> >
> > I would like it to be clarified what requirements (or even just
> > recommendations) are there to use CoAP vs HTTP for different
legs of
> the
> > exchange - not necessarily remove the flexibility but to
clarify for
> > implementers what can be done and what would be the reasoning
to do
> > that: for example if both endpoints support HTTP with the AS,
most
> likely you
> > can have HTTP between C and RS, so does it really make sense to
run
> this
> > instead of OAuth 2.0? Right now all is permitted, but does it
all
> make sense? I
> > feel like this type of considerations are missing. As a note -
I am
> not sure
> > what allowing a different encoding than CBOR for any leg of the
> exchange
> > adds to the specification - it makes things more confusing, and
if
> needed it
> > could be specified in another document.
> >
> > While going through and thinking about encodings (assuming we
keep
> the
> > doc as is with regards to allowing more than just CBOR), I
wondered
> if it
> > would be better to define a new media type to use when the ACE
> > framework is used with HTTP, to differentiate from OAuth 2.0,
since
> some of
> > the endpoints used are the same (/token and /introspect at the
AS).
> I am
> > interested to hear more from my co-AD as well if this would be
an OK
> use of
> > a new media type - I am thinking of the case where AS is
supporting
> both
> > OAuth 2.0 and the Ace framework - or if it is unnecessary,
since the
> > encodings are the same, and the parameters are registered in
OAuth
> 2.0
> > registry.
> >
> > More detailed comments below.
> > Francesca
> >
> >
> >
> ----------------------------------------------------------------------
> > COMMENT:
> >
> ----------------------------------------------------------------------
> >
> > Detailed comments:
> >
> > 1. -----
> >
> > sufficiently compact. CBOR is a binary encoding designed for
> small
> > code and message size, which may be used for encoding of self
> > contained tokens, and also for encoding payloads transferred
in
> > protocol messages.
> >
> > FP: "may be used" make it seem as if CBOR is always optional
(even
> when
> > CoAP is used). See points 11. and 13. for examples of text that
seem
> to imply
> > that CBOR is mandatory in some cases.
> >
> > 2. -----
> >
> > Refresh tokens are issued to the client by the
authorization
> > server and are used to obtain a new access token when the
> current
> > access token becomes invalid or expires, or to obtain
> additional
> >
> > FP: token validity - it is not clear what it means for a token
to
> become invalid
> > (vs expiring). As this is the first time it is mentioned, it
should
> be explained
> > here or referenced.
> >
> > 3. -----
> >
> > An asymmetric key pair is generated on the token's
recipient
> > and the public key is sent to the AS (if it does not
already
> >
> > inside the token and sent back to the requesting
party.
> The
> > consumer of the token can identify the public key from
the
> >
> > FP: "token's recipient" and "consumer of the token" - why not
talk
> about
> > client and resource server here? It would fit better with the
> terminology
> > used in the rest of the document.
> >
> > 4. -----
> >
> > This framework RECOMMENDS the use of CoAP as replacement
for HTTP
> > for
> > use in constrained environments. For communication security
this
> >
> > FP: This was already stated in the introduction in the following
> sentence:
> >
> > of processing capabilities, available memory, etc. For web
> > applications on constrained nodes, this specification
RECOMMENDS
> the
> > use of the Constrained Application Protocol (CoAP) [RFC7252]
as
> > replacement for HTTP.
> >
> > Not sure repeating is useful.
> >
> > 5. -----
> >
> > OAuth 2.0 (such as [RFC7521] and [RFC8628]). What grant
types
> works
> > best depends on the usage scenario and [RFC7744] describes
many
> > different IoT use cases but there are two preferred grant
types,
> > namely the Authorization Code Grant (described in Section
4.1 of
> >
> > FP: nit: s/works/work . I think "preferred" is probably not the
> right term
> > here, and should be rephrased or clarified - preferred respect
to?
> >
> > 6. -----
> >
> > In addition to the response parameters defined by OAuth
2.0 and
> > the PoP access token extension, this framework defines
> parameters
> > that can be used to inform the client about capabilities
of the
> > RS, e.g. the profiles the RS supports. More information
about
> >
> > FP: I believe this is a leftover from a previous version of the
> document, but
> > should be "profile" and not "profiles" as the AS is only
allowed to
> > communicate one profile to the client and RS - see for example
the
> following
> > sentences:
> >
> > The Client and the RS mutually authenticate using the
security
> > protocol specified in the profile (see step B) and the
keys
> >
> > The AS informs the client of the selected profile using
the
> > "ace_profile" parameter in the token response.
> >
> > 7. -----
> >
> > (1) the client sends the access token containing, or
> > referencing, the authorization information to the RS,
that
> may
> > be used for subsequent resource requests by the
client, and
> >
> > FP: s/may/will
> >
> > 8. -----
> >
> > While the structure and encoding of the access token
varies
> > throughout deployments, a standardized format has been
defined
> > with the JSON Web Token (JWT) [RFC7519] where claims are
> encoded
> > as a JSON object. In [RFC8392], an equivalent format
using
> CBOR
> > encoding (CWT) has been defined.
> >
> > FP: Would it make sense to RECOMMEND the use of JWT when HTTP is
> used?
> > Or is CWT always RECOMMENDED?
> >
> > 9. -----
> >
> > parameters. When profiles of this framework use CoAP
instead, it
> is
> > REQUIRED to use of the following alternative instead of
Uri-query
> > parameters: The sender (client or RS) encodes the parameters
of
> its
> > request as a CBOR map and submits that map as the payload of
the
> POST
> > request.
> >
> > FP: I think it should be better defined (or at least hinted in
this
> paragraph)
> > the mapping between the CBOR encoded parameters and the
Uri-query
> > parameters:
> > are they all encoded as CBOR text strings?
> >
> > 10. -----
> >
> > Applications that use this media type: The type is used by
> > authorization servers, clients and resource servers that
support
> the
> > ACE framework as specified in [this document].
> >
> > FP: I suggest adding "that support the ACE framework with CBOR
> encoding,
> > as specified ..."
> >
> > 11. -----
> >
> > The OAuth 2.0 AS uses a JSON structure in the payload of its
> > responses both to client and RS. If CoAP is used, it is
REQUIRED
> to
> > use CBOR [RFC8949] instead of JSON. Depending on the
profile, the
> > CBOR payload MAY be enclosed in a non-CBOR cryptographic
wrapper
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
