Subject: [Id-event] Fwd: Re: [saag] SecEvent Charter

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Sep 2016 13:31:27 +0100

Does anybody have an answer on this? Was netconf considered?
Is there shipping code for drafts in scope for SecEvent?

----- Original message -----
From: Kent Watsen <[email-masked]>
To: Kathleen Moriarty <[email-masked]>,
"[email-masked]" <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>
Subject: Re: [saag] SecEvent Charter
Date: Wed, 28 Sep 2016 00:38:44 +0000

Did anyone consider the overlap between this and event notifications
effort in the NETCONF working group?

  draft-ietf-netconf-rfc5277bis
  draft-ietf-netconf-netconf-event-notifications
  draft-ietf-netconf-restconf-notif
  draft-ietf-netconf-yang-push

It may not have the same focus, but it can get the job done, right?

Thanks,
Kent

On 9/27/16, 5:00 PM, "saag on behalf of Kathleen Moriarty"
<[email-masked] on behalf of [email-masked]>
wrote:

    Hello,
    
    A new working group has been proposed, SecEvent, that crosses
    between
    the ART and security areas.  This builds off of SCIM work, also
    leveraging OAuth, and will incorporate use of JWT from JOSE.  The
    working group, if approved, will go into the security area and I've
    agreed to AD it.  Please take a look at the charter under review:
    
    https://datatracker.ietf.org/doc/charter-ietf-secevent/
    
    And join the mailing list for discussion:
    https://mailarchive.ietf.org/arch/search/?email_list=id-event
    
    -- 
    
    Best regards,
    Kathleen
    
    _______________________________________________
    saag mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/saag

---

From: Phil Hunt <[email-masked]>
Date: Thu, 29 Sep 2016 09:54:32 -0700

Alexey,

Great question. There are certainly some overlap in requirements and goals around subscription management.

Regarding Implementation,
The SET Event work so far is a profile of the JWT (RFC7519) for secure event tokens and SCIM (RFC7643/7644) for subscription management so that we can build on existing implementations and stacks for rapid adoption.  We have proposed a very simple HTTP POST over TLS for delivery. The key profiling aspect of HTTP POST is to require the subscriber must not respond with acceptance (e.g. HTTP Status 202) unless the receiver was able to validate the message.

The OpenID Connect and RISC working groups have been putting events into test and are feeding back into the specs directly.  Connect’s Logout spec has already re-aligned with the SET token.

Regarding NETCONF, 
The community of participants (SCIM, OAuth, RISC, Connect, HEART, …) are largely focused on co-ordinating events between HTTPS based systems and endpoints using mostly JSON centric payloads. 

In contrast, my perception of NETCONF is it is working at a lower layer (network devices) and as such supports transmission using SSH (which is MTI) with largely XML structured data.  The current NETCONF MTI requirements would not be workable.

My perception of intent by most participants is to establish a contextual web of pub/sub relationships rather than message bus. So, there may not be much to be gained from aligning with NETCONF since the network configuration components are kept distant from the application security components.  

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Sep 28, 2016, at 5:31 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event