On Tue, Jul 02, 2024 at 02:10:17PM +0200, Christian Amsüss wrote:
> 1. Wrap the AIF and some indicators for the extra data in some kind of
>"bag" structure.
With how tokens spanning groups was described in today's session, there
might be overlap for these items: let
Hello AIF experts and ACE group,
looking into AIF (in particular the REST-specific model) for use on
embedded (RIOT OS based) systems, there are properties I'd like to
express additional properties in a token, eg:
a. "When responses are sent to a client authorized with this token, the
server m
Hello Sree,
On Fri, May 17, 2024 at 02:57:24PM +0200, sree lakshmi wrote:
> In this draft, we have assumed a pre-established mutual authentication
> step between the DO and the AS. We haven’t explained it in detail
> because it is an assumption.
The assumption I've been working on is that DO is e
Hello Sreelakshmi, authors, ACE,
I've read draft-vattaparambil-ace-wg-poa-device-reg-00 and think it
provides a valuable contribution to ACE, especially if it grows to
actually propose an interface to the client registration problem.
I am not sure that the proposed solution has the ideal work flow
Hi Carsten,
On Sun, Jul 23, 2023 at 03:10:43PM +0200, Carsten Bormann wrote:
> Whether anyone whose statements you are willing to base your
> authorization on is willing to endorse the manufacturer’s claims is
> one of the authorization questions hidden in attestation…
As I understand there can a
Hello Michael,
(Group(s): See especially PS at the bottom)
thanks for your feedback, that's the very kind I was hoping for.
On Wed, Jul 12, 2023 at 05:52:30PM -0400, Michael Richardson wrote:
> IN section 1.1, without having given a picture of what you are doing
> you start to say:
> "The
Hello Michael,
On Wed, Jul 12, 2023 at 06:57:38PM -0400, Michael Richardson wrote:
> I don't think this belongs in t2trg, but I don't object.
> maybe it goes into ACE or IOTOPS.
I'll appreciate if any of those wanted it; first people I've talked to
about it pointed me to T2TRG. I'll try to get a
Hello T2TRG (because of its researchy character),
hello ACE (because this is applied to your ecosystem),
motivated by project requirements, I've written a draft[1] on how
devices without reliable Internet connectivity (and thus time source)
can deal with time limited tokens.
> Abstract:
>When
Hello ACE and ANIMA groups,
hello Ben, Michael and Russ,
taking input from the "ANIMA and ACE, IDevID terminology" thread[1],
where the discussion was lacking a concrete proposal, I've written up
things at [2].
I'd appreciate the one or other pair of eyes, and feedback both on the
direction and t
Hi Ben,
On Mon, May 01, 2023 at 10:41:32PM -0700, Benjamin Kaduk wrote:
> > * Does pinned-domain-pubk work also for COSE keys as used for signed
> > CWTs? (If so, is there a key identifier to go with it?)
>
> COSE key identifiers ('kid') are not exactly what you would typically call
> a "key id
Hi Michael,
(CC'ing ACE list because what I think will be the larger part of the
thread is hopefully relevant)
> > there a generalization of the IEEE identifiers that also makes
> > sense for constrained but more general-purpose-oriented devices,
> > for which the ANIMA products can st
Hello group,
On Mon, Sep 12, 2022 at 06:04:18PM +0200, Christian Amsüss wrote:
> I've read this document and can review it in its working group phase.
as I was asked off-list to clarify: I very much do support this document
for adoption into this working group.
BR
c
signature.asc
Des
Hello chairs, group,
On Mon, Sep 12, 2022 at 11:26:21AM -0400, Daniel Migault wrote:
> This work stats a Call for adoption of the following document:
> Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for
> Constrained Environments (OSCORE) Profile for Authentication and
> Authorizat
Hi,
sorry for spreading this out over the sub-threads[1], just to get the
pointers right and everything addressed:
On Fri, Sep 03, 2021 at 08:32:59PM +0200, Rafa Marin-Lopez wrote:
> 2) When the CoAP message contains the OSCORE ID that hits the OSCORE
> context without any key material, we woul
Hello Rafa,
that's the mail I missed in our previous discussion -- and yes, it
largely describes already just what I think can work, see comments
below.
On Sat, Sep 04, 2021 at 09:19:35PM +0200, Rafa Marin-Lopez wrote:
> I think that is not possible because that would move the EAP peer
> state ma
Hello Dan & Rafa,
On Fri, Sep 10, 2021 at 10:42:56AM +0200, Dan Garcia Carrillo wrote:
> > * OSCORE ID derivation:
> >
> > * Randomly assigned full-length ideas look like an odd choice.
> > [...]
> >
> > Any chance something like that can still make it in?
>
> [Authors] Did not see
Hello,
(picking some easy targets to advance, not touching parallel or earlier
discussion),
On Fri, Sep 10, 2021 at 10:42:56AM +0200, Dan Garcia Carrillo wrote:
> > IoT device Controller
> > ++ ++
> > | EAP peer/ |
Hello,
On Sat, Aug 14, 2021 at 01:37:06PM +0200, Dan Garcia Carrillo wrote:
> As such, CoAP server (left side) could not see the content of the CoAP
> message (message 7) without deciphering it. Moreover, as the URI-path is
> also ciphered we cannot point to the right application to process the
>
Hello CoAP-EAP authors and involved groups,
(CC'ing core@ as this is a review on CoAP usage),
I've read the -03 draft and accumulated a few comments; largely in
sequence of occurrence.
Over all, the protocol has improved a lot since I've last had my eyes on
it. Several comments below are about h
Hello ACE,
On Thu, Dec 03, 2020 at 01:20:08PM +, Daniel Migault wrote:
> It seems ACE to me that ACE could be home for such a document. I am
> wondering if emu core or any other WG believe there is a better place
> for it.
If nothing else, I'd be curious to see EAP-over-CoAP this sketched out
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 ther
Hello Francesca, hello ACE group,
On Mon, Sep 21, 2020 at 01:48:33PM +, Francesca Palombini wrote:
> - clarified that Appendix B.2 of OSCORE can be used with this profile,
> and what implementers need to think about if they do.
I understand B.2 to be something that the involved parties need t
Hello John, Jim,
and ACE in general,
I agree with Jim that namespacing is the obvious solution to this
problem; we've had a brief discussion in a WG meeting shared with OCF
earlier this year.
However, the namespacing of KIDs is a difficult matter[1] and moreover
little understood so far. I'm unaw
Hello ACE,
piecing together parts of the big picture of Resource Directory, CoRAL
forms and ACE, I was wondering where in the whole story the client
should tie its intention to the key material it uses to authorize an
action.
Take this -- admittedly contrived, but hopefully illustrative example:
Hello ACE,
I've read through draft-tiloca-ace-oscore-gm-admin. Its value is in that
it fixes a gap in the set of current drafts on the topic:
Without (something like) this, group deployment applications need
application specific group managers, and as the GM is not trivial to
implement, I'd expec
25 matches
Mail list logo
