►
From YouTube: IETF100-SECEVENT-20171113-1330
Description
SECEVENT meeting session at IETF100
2017/11/13 1330
https://datatracker.ietf.org/meeting/100/proceedings/
C
C
C
C
D
We'll
do
more
later
on,
there's
definitely
a
lot
of
discussion
there
next
slide
so
security
events
started
about
two
years
ago
we
were
looking
at
an
observing
in
Tokyo
that
we
were
all
writing
drafts
for
log
out
for
token,
revocation
for
skim
events
for
risk
events
and
Justin
had
another
group
for
I
think
was
healthcare
consent
called
heart.
We
were
all
using
jot
and
the
comment
was
in
Tokyo.
D
Maybe
we
can
have
a
common
foundation
draft
that
sets
out
all
the
security
considerations
and
privacy
considerations
and
the
basic
form
so
that
we
could
take
current
libraries
for
ja
and
enhance
them
to
do
sets,
and
that
would
lay
a
foundation
for
other
specs,
like
heart,
like
risk
to
specify
events
that
work
in
their
communities
that
design
assumed
independent
development.
There
is
no
formal
reconciliation
mechanism.
That
was
how
it
was
started.
D
Events
themselves,
something
to
point
out
that
when
we've
at
our
first
meeting,
some
people
from
the
broader
IETF
community
pointed
out
that
there
are
very
different
perceptions
on
events,
so
some
people
believe
an
event
is
something
like
an
antivirus
thing,
where
I've
collected
a
bunch
of
data
and
drew
a
bunch
of
historical
data
and
made
a
conclusion,
that's
one
definition
of
an
event.
Another
definition
of
event
is
it's
a
command
that
one
party
sends
to
another
yeah.
So
this
group
is
neither
of
those
things.
D
It's
really
simply
one
domain
sending
a
trigger
a
simple
statement
from
one
domain
to
another
that
can
be
interpreted
by
the
receiving
party
to
decide
what
to
do
so.
We're
kind
of
smack
dab
in
the
middle
of
doing
that.
There's
lots
of
good
reasons
for
that.
If
you
think
about
major
providers,
don't
necessarily
want
to
talk
a
lot
about
how
they
came
to
a
conclusion.
D
Nor
do
they
want
to
be
in
the
business
of
telling
their
competitor
what
to
do
so
skim
kind
of
defines
its
event
right
down
the
middle,
so
the
timeline
at
the
bottom
was
this
work.
We
started
writing
the
drafts
in
November
we
were
initially
looking
at
an
ad
sponsored
track
and
then
quickly
after
a
joint
meeting
with
the
skin
working
group
in
Buenos,
Aires
decided
to
work
on
a
charter
for
this
group,
and
so
now
we
are
here
today.
Next
slide.
C
D
So
this
is
just
listing.
The
examples
I
just
mentioned
before
skimmers
perspective
was
that
you
had
a
RESTful
API,
where
a
client
wants
to
send
changes
and
pull
data
from
a
service
provider.
But
what
we
found
was
a
need
for
the
service
provider
to
be
able
to
send
signals
or
triggers
back
to
those
clients,
so
that
the
client
can
decide
what
to
do
about
things.
D
If
you
think
about
a
service
provider,
they
have
many
clients
or
thousands
of
clients,
each
introducing
changes
and
the
service
provider
wants
to
coordinate
some
of
those
changes
in
OAuth
we've
been
talking
about,
but
haven't,
started
work
on.
How
do
you
revoke
an
access
token?
There
is
an
RFC
to
tell
the
ASO
you
want
that
token
revoked,
but
there's
no
method
right
now
for
the
a
s
to
let
the
audiences
know
that
that
token
was
actually
revoked.
D
So
that's
a
back-channel
not
listed
here
is
the
back-channel
logout,
which
is
simply
how
to
facilitate
a
logout
and
a
back-channel
risk.
Is
you
have
security
systems
want
to
share
security,
generated
events
between
parties
and
then
hard
as
I
mentioned?
Is
it's
the
ability
to
share
consent?
Events
in
a
signed
format
so
we'll
go
to
the
next.
There.
C
D
Let's
yeah
so
for
draft
two,
there
was
a
working
group
last
call
put
out.
We
took
the
feedback
from
Oh
and
we
generated
a
no.3
as
history.
We've
now
had
four
working
group
drafts,
and
that
was
preceded
by
eight
individual
draft
updates,
starting
from
two
years
ago,
as
far
as
the
implementation
goes,
and
the
draft
goes
up
until
now,
it's
been
what
I
would
characterize
is
functionally
stable.
Next
next
slide
there
were
a
few
editorial
changes.
There
were
a
couple
of
old
terms.
D
We
had
we
used
to
have
publish
and
subscribe
as
a
term,
and
there
were
a
few
left
over
subscribed.
Words
left
so
I
fixed
that
we
clarified
that
an
event
receiver
is
in
fact
the
same
thing
as
JWT
recipient.
However,
for
editorial
reasons,
we
decided
to
keep
it
consistent
as
transmitter
receiver,
rather
than
actually
switch
over
to
recipients.
So
I
made
the
clarification
and
the
definitions.
D
It
was
also
brought
up
that
we
were
redefining
not
before
for
a
different
purpose
and,
as
a
general
rule,
we've
not
like
that,
so
we
decided
to
remove
NBF
and
define
something
which
is
what
people
really
wanted,
which
was
time
of
event.
This
enables
things
such
as,
if
you
notice
a
week
later,
that
something
happened
like
a
password
database
was
compromised.
You
can
issue
the
event
after
the
effect,
so
the
time
of
the
set
and
its
issuance
may
not
in
fact
correspond
to
what
you
believe
the
actual
time
of
event.
D
So
if
that's
important,
there's
a
registered
claim
and
Ja
now
to
do
that,
that's
it.
So
this
is
the
part.
That's
happened
since
we
posted
oh
three
Thank,
You,
Annabelle
and
Annabelle's.
Thought
was
what,
if
we
just
take
the
events
attribute
and
make
it
singular.
William
Dennis
pointed
out
that
there
may
be
some
confusion
that
we
have.
The
word
call
the
claim
events,
meaning
there
are
multiple
things
inside
that
JSON
attribute,
but
that
we're
still
conveying
one
logical
event.
D
D
D
So
basically,
it's
the
same,
except
that
you
now
have
a
vent
and
you
do
not
have
multiple
payloads.
Instead,
you
have
attributes
of
the
event
directly
in
there's
one
specified
to
be
called
an
event
type,
which
is
how
you
indicate
what
type
of
event
it
is
and
then
any
of
the
other
things
you
want
in
there
can
be
added
in
so
Annabelle
had
translated
the
skim
example,
and
this
is
what
it
would
look
like
with
the
new
format
next
slide.
D
So
the
argument
was
one
event
is
simple
and
that
it's
simple,
because
some
receivers
don't
know
how
to
handle
multiple
payloads
they
might
get
confused
over
which
payload
is
the
actual
event
or
the
primary
event
and
so
processing.
Multiple
events
is
seen
as
complex
for
some,
so
I'll
leave
that
there
and
Annabelle
can
add
to
that
later,
because
we're
not
always
in
sync
on
what
I
think
she's
after
so
this
was
the
comment
that
William
made
that
events
does
suggest
multiple
events.
D
But
if
you
look
at
the
spec,
it
doesn't
actually
permit
distinct,
repeat
events,
because
you
can't
actually
repeat
the
same
event
payload.
You
can
only
specify
at
once.
So
you
couldn't
actually
say
use
asset
to
convey
five
separate
transactions.
You
could
convey
five
different
pieces
of
information
or
any
pieces
of
information
about
the
same
logical
event
that
works.
That's
allowed
at
the
moment.
Next
slide.
D
So
the
oath
redraft
the
way
it's
written
it
kind
of
my
feeling
was:
is
that
the
the
allowing
multiple
event
URI
payloads
allows
you
flexibility
with
what
how
you
want
to
handle
versioning
flexibility
as
to
how
you
handle
extensions?
In
other
words,
an
extension
payload
looks
exactly
like
an
event,
payload
they're
processed.
Exactly
the
same
way,
the
downside
to
that
is
confusion
over
which
one
is
the
actual
event
that
matters
I
also
was
thinking
about
this
saying
you
could
have
a
utility
profile
on
the
example
from
the
risk
group
is.
D
One
of
the
other
features
that
that
many
people
have
had
from
the
beginning
is
the
ability
to
develop
specs
on
the
fly,
which
is
why
we
chose
event
types
as
expressed
as
URIs
rather
than
you
are
ends,
and
a
lot
of
people
said.
Ok,
I
might
take
a
skim
event
or
a
risk
event,
but
I
might
want
to
add
more
data,
because
the
partner
on
sharing
events
with
is
really
part
of
my
administrative
domain
and
we're
going
to
share
more
data.
I
can't
see
a
reason
why
not-
and
that
seems
reasonable.
D
D
So
it's
an
example:
I
looked
at
there's
an
event
from
the
old
skim
profile
draft
where
there's
a
password
reset
function,
and
we
described
an
extension
to
that
as
a
hypothetical
extension
where
you
say
might
also
be
useful
if
some
providers
want
to
tell
their
receivers
the
number
of
password
resets
that
have
occurred
and
out
of
counter
to
that
so
go
to
the
next
slide,
does
the
bill.
So
this
disorder
describes
an
event
where
the
extension
is
really
doesn't
stand
on
its
own.
D
It
has
to
be
shipped
with
the
primary
event
the
password
reset,
but
if
we
look
at
the
perspective
of
another
community,
the
risk
community,
they
have
some
overlap
and
they
have
an
event
that
covers
this,
but
in
a
broader
sense
and
go
the
next
slide.
So
the
risk
account
credentials
require
somewhat
overlaps
in
the
sense
that
that
change
might
boil
down
to
a
password
reset
or
it
might
be
something
else.
D
It's
a
broader
context
event
one
of
the
differentiators
is
that
risk
tends
to
come
from
a
security
calculation,
whereas
the
skim
event
is
often
triggered
in
the
normal
course
of
business.
The
user
asked
for
an
account
reset
and
that's
what
happened,
whereas
in
risk
generally,
but
not
always
it's
the
feeling
is
some
security
system
perform
some
calculation
and
came
to
the
conclusion
that
an
account
credentials
required.
So
if
we
go
to
the
next
slide,
the
question
then,
is:
if
I
send
these
all
together
in
one
set.
D
The
scenario
could
describe
that
the
event
was
triggered
by
the
security
system
and
that
security
system
as
part
of
that
same
transaction,
it
has
caused
a
scheme
system
to
do
a
password
reset
as
part
of
that
or
an
other
interpretation.
Is
that
there's
a
count
change
required
because
there's
been
five
resets,
it
depends
on
the
relationship
and
what
the
sequence
of
events,
but
this
becomes
possible
to
Express.
D
D
D
Okay,
so
on
the
left
in
the
current
proposal,
we
have
events,
and
the
format
is
that
under
events,
the
next
object
is
an
event
URI
attribute,
and
then
this
JSON
object
is
what
we've
been
referring
to
as
the
payload.
The
second
payload
is
here,
which
is
the
skin
or
the
risk
event
and
its
payload
below
that
says.
Here's
what's
going
on,
and
then
this
skin
Password
Reset
it's
complete
here.
The
extension
is
skin.
D
One
thing
I
wonder
about
is:
what
is
the
format
of
this
section
does
which
looks
a
lot
now
like
that,
and
what
is
the
format
over
here?
You
have
multiple
formats
that
might
not
be
the
way
skim
does
it.
That
might
not
be
the
way
risk.
Does
it,
but
the
concern
I
have
is
there
would
be
no
standards
for
Interop
own
extension
mechanisms.
Maybe
that's
good.
Maybe
that's
bad
next
slide.
D
D
Would
you
draw
different
conclusions,
it's
hard
to
say
and
I
think
this
comes
about,
because
the
skin
working
group
is
working
independently
from
the
risk
working
group
which
may
be
also
overlapped
by
another
future
working
group
from
the
payment
card
Association
or
some
other
indriyas
industry
association,
so
I
kind
of
suggested
that
we
have
some
flexibility
that
when
things
overlap,
you
can
convey
them
together
to
give
the
bigger
picture
of
the
bigger
hole
and
let
the
receiver
draw
the
conclusion.
Phil.
C
D
The
skin
working
group
is
closed
at
the
moment
in
its
charter.
It
has
an
unresolved
issue
called
event
triggers
what
actually
happened
was
we
started
working
on
that
and
decided
to
broaden
broaden
this
back
and
at
the
skin
working
group
it
was
agreed
to
move
forward
on
a
sec
events
working
group
as
a
separate
working
group.
So
at
the
moment
we
have
not
resurrected
the
skin
to
complete
the
skin
profile,
because
the
work
was
transferred
here.
C
C
D
So
this
was
just
the
author's
recommendations
for
a
number
of
reasons.
We
felt
that
you
can
accomplish
a
single
event.
If
you
want
to
the
optionality:
is
there
I
spoke
to
Annabelle
just
before
the
meeting,
and
the
optionality
does
become
a
concern,
though,
for
some
transmitters
who
may
not
be
able
to
send
a
combined
event.
D
Receivers
can
say:
I
just
want
a
risk
events
and
risk
events
only
or
skiing
events
and
scheme
events.
Only
that
that's
already
there
that's
in
the
spec
there's
nothing
saying
that
that
that
the
event
can't
contain
a
single
event.
The
issue
is:
does
it
require
a
transmitter
to
combine
events?
If
that's
what
the
receiver
wants
and
I
think?
That's
the
concern.
D
From
a
process
perspective,
my
conclusion
looking
at
it
that
we
would
be
starting
with
a
new
internet
draft
proposal
and
starting
over
if
we
want
to
go
this
way
so
because
of
all
of
that,
our
recommendation
is
to
leave
it,
as
is
maybe
we
have
some
clarification
on
optionality
and
that's
it.
So.
The
next
slide
is
discussion,
and
we
can
do
some
of
that,
or
do
it
later
well,.
C
F
Justin
richer
as
progenitor
of
the
current
syntax
in
the
document.
After
having
heard
Phil's
argument
for
keeping
the
current
syntax
I'm,
actually
leaning
towards
Annabelle's
proposed
new
syntax,
specifically
because
the
idea
behind
the
current
syntax
was
to
make
it
easier
for
the
receiver
of
the
set
to
be
able
to,
as
Phil
said,
you
know,
go
in
I
just
want
this.
One
thing:
I
just
want
this
one
aspect
of
this
event
that
I
care
about
it
was
never
intended
to
carry
multiple
events
in
a
single
payload.
F
It
was
meant
it
was
meant
to
carry
multiple
aspects
of
a
single
event
in
a
payload,
and
that's
why
it's
expressed
as
as
a
hash.
The
way
that
it
is
today.
I
think
that
we
want
off
the
rales
in
terms
of
extensions
and
all
of
this
other
stuff
and
sort
of
primary
versus
secondary
events,
and
all
of
that
complexity
is
now
leading
me
to
believe
that
we
really
do.
We
would
be
well-served
to
pull
that
back
into
something
that
is
more.
No.
F
C
G
Believe
that
these
actually
need
to
be
together
so
they're
risky.
So
we
have
cases
where
we
have
risks
risk
event
followed
by
skin
events
in
the
same
thing
in
the
same
payload
and
it
right
now.
If
we
get
a
password,
if
we
get
a,
you
know
account
change
or
something
we
will
also
throw
in
the
skin
events
into
the
same
payload.
G
G
I'm
not
sure
I
would
force
but
I
think
if
you,
if
you
receive
them,
you
have
to
understand
so
I
mean
it's
gonna
come
down
to
that
I
mean
if,
if
we
happen
to
bundle
them
all
together,
you
would
have
to
understand
the
bundle
together.
If
you
send
them
separately,
we
all
have
to
understand
them
separately.
C
F
That
was
never
in
our
use
cases.
That
was
never
the
intended
interpretation,
and
so
I
did
not
anticipate
that
being
an
interpretation
when
we,
when
we
originally
put
that
forward.
But
if
that's
what
people
are
doing,
I
think
that's
a
bad
idea
and
they
should
be
carried
separately.
There's
there
is
some
Jose
overhead
of
multiple
signatures,
and
things
like
that,
but
I
think
that
the
the
clarity
gained
is
probably
worth
it.
E
H
C
H
G
A
So
changes
since
IETF
99
I
point
to
the
current
draft,
the
previous
one.
There
are
very
few
changes.
One
notable
change
is
that
the
verification,
even
definition,
moved
to
a
management
API.
So
this
is
a
special
event
which
allows
transmitters
to
just
verify
that
the
line
or
the
best
delivery
is
still
alive
or
allows
receivers
to
to
request
one
of
these
just
to
make
sure
that
the
connection
still
works.
A
Now,
moving
on
to
open
questions,
so
one
big
open
question
is
that
we
define
the
spec
defines
to
delivery
methods.
One
is
ATT,
HTTP
POST
define
a
push
delivery
method,
the
other
one
defines
the
polling
delivery
method
and
many
transmitters
expressed
the
fact
that
they
want
to
implement
one
or
the
other
are
not
both.
A
A
Another
thing
is
these:
delivery
methods
all
require
some
attributes
I
give
some
examples
there.
So
for
the
push
deliver
is
an
endpoint
and
potentially
an
authorization
header.
The
polling,
delivery
method
needs
an
end
point,
but
this
end
point
it's
written
is
defined
by
the
transmitter
and
we
are
looking
at
formal
methods
where
the
Divali
methods
can
define
here
are
the
attributes
needed
for
an
implementation,
and
then
management
api's
can
define
ways
how
these
are
set
and
retrieved.
G
A
A
That's
a
requirement
that
many
people
express
I
agree
with
that.
But
my
question
is
because
the
feedback
we
got
so
far
is
that
IETF
doesn't
like
specs,
which
has
optional
components
to
it.
Maybe
that's
acceptable
and
if
that's
acceptable,
it's
fine.
If
not,
then
we
need
to
find
a
way
to
achieve
that.
I.
D
Think
it's
Phil
here,
I
think
the
optionality
might
be
the
wrong
sense.
To
think
about
this
is
that
you?
It
depends
on
what
your
network
scenario
is
if
you're
trying
to
get
through
a
firewall
that
you
can't
otherwise
get
through.
You
don't
really
have,
but
there's
no
optionality:
if
you're
going
to
send
an
event
polling
is
the
only
thing
that's
going
to
work.
So
it's
more
of
a
you
got
to
use
the
tool
you
have
to
use
to
get
it
done
and
that's
why
we
have
two
optional
specs,
so
so
I
think
the.
D
H
Anabelle
back
men,
so
I
think
that
concern
I
see
there's
if
an
implementer
says
I
support
set
delivery
over
HTTP.
What
does
that
mean
if
I'm
trying
to
inter
up
with
them?
What
does
that
mean
to
me
if
both
are
optional,
then
that
on
its
own,
doesn't
really
tell
me
anything
I
need
to
know
okay,
which,
within
the
set
delivery
over
HTTP?
What
did
you
actually
implement?
D
I
think
the
concern
is
that
the
client,
the
receiver,
doesn't
have
a
choice,
he's
either
A
or
B.
They
either
have
an
openly
accessible,
API
endpoint,
where
they
can
receive
events
or
they
don't
so
they
don't
have
a
choice.
They
have
a
requirement
that
they're
expressing
and
then
it's
really
up
to
the
transmitter
to
say.
Do
I
want
to
be
able
to
send
events
depending
to
that
receiver,
given
they
don't
have
a
choice.
Maybe.
C
H
A
I
C
D
Fill
again
to
clarify
I,
don't
believe
it's
a
profile
issue,
because
whether
it's
risk,
whether
it's
skim
or
heart,
it
really
depends
on
the
network.
Reality
that's
out
there.
It
doesn't
have
anything
specifically
to
do
with
profile.
Although
it
may
be
true
that
some
profile
out
there
doesn't
have
any
network
differences
that
they
have
to
be
concerned
about,
so
they
could
rule
one
out,
but
in
general
I
think
at
the
SEC
events
level
it
depends
on
what
the
client
needs
and
whether
you
want
to
support
that
client.
H
Annabel
Backman
up
it's
true
that
the
network's
situation
that
the
receiver
has
is
kind
of
a
limiting
factor
for
them
that
doesn't
change.
The
fact
that
having
one
or
both
of
these
is
optional
in
the
spec
introduces
ambiguity
for
them
as
far
as
understanding
what's
available
to
them.
If
you
are
a
receipt
who
cannot
expose
endpoints
such
that
polling
is
a
requirement
for
you,
then
again,
seeing
a
transmitter
describe
themselves
as
supporting
set
delivery
over
HTTP
still
doesn't
tell
you
can
I
interrupt
with
this
person?
H
A
A
No
I
think
we
can
move
past
their
attributes,
and
here
is
an
example
of
how
attributes
would
be
used,
for
example,
in
an
API
which
allows
you
to
query
the
state
of
an
existing
stream.
I
highlighted
in
bold,
for
example,
the
delivery
method,
URI
a
URL
parameter,
which
is
the
endpoint
where
events
are
pushed
or
post
to
post
and
an
example,
authorization
header
just
to
have
a
visual
example
of
what
these
attributes
mean.
A
A
The
main
requirement
for
this
one
was:
it
comes
from
preventing
denial
of
service
attacks
and
basically
this
proposal
is
to
allow
receivers
to
space.
It
specify
the
full
authorized,
HTTP
authorization,
header
and
it's
up
to
the
receiver.
For
example,
it
can
define
basic
auth
or
API
key
or
even
an
access.
Token
is
if
it's
longer-lived
and
they
can
refresh
it
periodically.
C
I
F
A
F
Your
main
question
question-
and
this
is
my
response
to
that
question:
if
that
is
what
I
keep
hearing
the
refrain
of.
Oh
that's,
Ana
profile.
Oh
that's
in
a
profile,
oh
that's
in
a
profile,
and
it
it
really
makes
me
wonder:
what's
left
in
a
security
of
that,
so
when
we
first
came
together
to
talk
about
security
events,
a
lot
of
you
already
know
this.
It
was.
It
was
fairly
simple
concept
in
that
you
put
a
bunch
of
stuff
in
the
envelope
that
says
this
is
what
the
you
know.
F
We've
gone
a
long
way
from
there
now
and
I
am
really
afraid
that
this
mantra
of
oh,
we
will
make
a
profile
that
specifies
you
know
how
we
authorize
the
push,
call
or
something
like
that.
How
we
do
time
of
event
how
we
do
subject,
how
we
do
anything
is
leaving
precious
little
for
the
set
to
actually
define,
because
it's
kind
of
stripping
it
down
and
saying
it's
just
JA.
And
so,
if
you
have
a
bunch
of
independent
working
groups
that
all
agree
to
just
use
jots,
why
do
they
care.
G
G
C
A
A
I'm
gonna
present
an
event
management
API.
We
are
going
to
talk
about
two
management
api's
today,
this
one.
It's
a
it's
a
simple
one:
breast
inspired,
not
necessarily
a
REST
API,
but
it's
a
simple
API
with
some
all
consumer
clients
in
mind.
So
we
have
a
proposal
for
this
one
at
IDF
99
we
presented
it.
It's
an
individual
draft.
A
We
split
out
a
stream
status
operation.
The
verification
event
definition
was
moved
from
the
devel
respect
into
this
one
and
then
a
security
consideration.
Sections
was
added
all
right.
So
now
we're
gonna
look
at
the
API.
I'm
gonna
probably
go
quickly
through
these
slides
and
you
let
me
know
if
you
need
to
stop
anywhere,
but
so
get
stream
cook
config.
This
is
the
request.
A
A
D
D
A
A
There
is
an
example
here
of
adding
a
subject
based
on
an
email
address
again
the
exact
way
the
subjects
are
identified.
It's
expected
to
be
done
in
a
profile.
You
know
here
it
and
the
phone
number
below
it
are
just
pure
examples,
but
basically
it's
supposed
to
an
endpoint
and
then
some
way
to
identify
which
subject
needs
to
be
added.
A
F
I,
don't
think
it
really
makes
that
much
sense
either.
So
we
a
toy
around
with
the
idea
of
a
what
we
were
calling
the
shoebox
endpoint
so
in
in
most
of
the
heart
use
cases.
Think
of
these
event,
token
things
as
being
receipts
for
something
happening
during
a
transaction
right.
So
I
give
my
doctor
access
my
doctor
accesses
things.
Those
are
discrete
events,
things
happen
and
I
want
some
record
of
those
things
happening.
C
F
D
On
the
skin
side,
it
is
possible
we
might
use
this,
particularly
when
skin
is
used
in
the
consumer
environment
in
the
enterprise
environment.
You
tend
to
be
put
into
a
group,
and
the
group
defines
whether
you're
going
to
whether
events
are
going
to
be
sent
for
that
person
on
the
basis
of
the
group
or
there's
some
filter
on
an
entitlement
attribute
that
says
we're
sharing
data
about
you
with
Salesforce,
because
you're
configured
to
have
a
Salesforce
CRM
account
and
it's
all
set
up.
D
A
And
so
your
question
as
well
so
for
the
removes
subject,
maybe
move
on
to
the
next
one,
one
more
okay,
so
for
the
remove
there
might
be
a
use
case
even
in
the
oils
use
case
right
when
the
user
actually
wants
to
opt
out,
and
there
is
explicitly
a
receiver
note,
do
not
send
or
do
not
process
risk.
Events
on
my
behalf
and
there
might
be
a
use,
is
there
where
an
explicit
call
IDs
might
still
be
necessary.
It's
not
clearance.
H
A
A
A
A
Some
future
work
to
allow
receivers,
to
specify
supported
events
and
to
allow
transmitters
to
declare
the
supported
events
by
them.
So,
basically
a
transmitter
can
say:
I
support
these
five
events.
The
receiver
say
I'm
interested
in
these
five,
but
only
three
of
them
overlap
and
then
the
actual
on
the
actual
stream
potential.
Only
those
three
events
what
would
be
flowing.
A
A
A
One
need
one
thing:
we
need
to
clarify
it's
how
to
distinguish
between
read-only
and
readwrite
configuration
parameters.
When
we
get
the
configuration
of
a
stream
using
an
HTTP
GET,
we
get
an
a
JSON
blob,
some
of
them
are
read.
Only
some
of
them
are
read
right
when
we
posed
back
to
the
same
input
to
change
some.
There
is
space
for
confusion
here,
and
it's
not
clear
how
we
should
deal
with
that
next
and
also
there
is
the
we
keep
talking
about
a
discovery
document.
A
It's
not
clear
if
this
management
API
is
the
right
place
for
a
discovery
document.
The
current
proposed
brainstorming
is
to
have
something
very
similar
to
a
discovery
document
done
in
open
ID
connect.
A
very
similar,
well
known-
and
here
is
a
JSON
blob-
is
describing
such
potential
discovery
document
for.
H
Okay,
so
I'm
Annabel
Backman
I'm
going
to
be
presenting
how
we
are
profiling.
What
Marius
just
talked
about
in
the
risk
working
group
where
we're
at
with
that?
So
we've
had
a
lot
of
talk
about
this,
we'll
go
to
the
profile.
That'll
go
to
the
profile,
let's
walk
through
an
example
of
what
that
might
look
like,
so
just
to
get
everyone
on
the
same
kind
of
baseline.
The
use
cases
that
risk
has
for
a
management.
Api
are
these
five
here
for
what
we
call
in
risk
implicit,
relying
parties.
H
These
are
parties
such
as
Amazon,
where
we
do
not
directly
depend.
We
don't
have
an
open,
ID
connect
relationship
with
Google,
but
we
have
a
lot
of
customers
who
use
their
Gmail
account
as
their
forgot
password
mechanism.
So
we
sort
of
implicitly
depend
on
the
security
of
that
gmail
account
for
our
piece
like
us.
We
need
a
way
to
explicitly
enroll
and
say
hey.
We
want.
We
need
events
about
this.
This
account
because
they've
started
using
our
system.
H
Similarly,
I
think
unenroll
events.
We
talked
through
a
little
bit
about
that
about
the
use
cases
for
that
just
a
Mon
ago.
So
you
heard
that
those
apply
to
risk
as
Marius
showed,
there's
a
need
for
receivers
to
specify
what
kind
of
events
they
can
receive
or
they
want
to
receive
from
a
transmitter.
So
we
need
a
mechanism
for
that.
We
need
a
mechanism
to
say
how
we're
gonna
receive
these
events,
what
endpoints
and
then
we
want
to
have
a
mechanism
to
make
sure
that
a
particular
stream
is
active
and
functional
there.
H
So
one
of
the
things
we
talked
about
earlier
it
was
authorization
and
the
need
to
figure
out
how
to
profile
that
well,
there's
also
the
question
of:
how
do
we
authorize
the
management
API?
So
we've
said
in
risk
is
the
management
API
will
be
use
the
HTTP
authorization,
header
and
we'll
use
bearer
tokens.
H
H
So
there's
three
main
types
of
subjects
that
we
have
talked
about
in
risk.
Marius
mentioned
the
need
to
be
able
to
define
different
subject
types,
so
this
is
what
we're
looking
at
in
risk
right
now,
there's
a
subjects
that
are
primarily
identified
by
email,
address,
subjects
identified
by
a
phone
number
and
then
subjects
identified
through
an
issuer
in
subject
pair,
as
you
would
see
in
an
open,
ID
connect
relationship,
we've
defined
a
structure
here
that.
H
H
H
H
The
other
last
thing
I
want
to
talk
about
here
is
discovery
and
what
we're
looking
at
at
the
risk
level
for
that
there's
a
lot
of
things
that
we
could
think
of
when
we
talking
about
discovery
just
to
be
clear-
and
the
first
thing
that
might
come
to
mind-
is
the
event
stream
capabilities.
What
types
are
supported,
what
delivery
methods
are
available?
We're
not
talking
about
that
here.
Next,
we're
not
talking
about
that
here.
What
we're
interested
in
or
these
this
other
point,
this
question
of:
how
are
we
discovering
the
management
API?
H
And,
secondly,
how
are
we
discovering
who
to
talk
to
in
the
first
place,
given
an
identifier
earlier,
I
talked
about
Amazon
wanting
to
receive
events
about
a
gmail
account.
That's
pretty
easy,
because
a
gmail
account
is
Gmail.
Everybody
knows
that's
Google
who
who
runs
that,
but
there
are
a
whole
lot
of
other
email
addresses
out
there
and
then
there's
things
like
phone
numbers
where
it's
completely
unclear,
given
the
phone
number,
whose
authoritative
for
that
or
not,
so
we
need
mechanisms
to
identify
that
for
different
identifier.
H
Types
next
slide
yeah,
so
something
we've
discussed
is
having
specific
discovery
mechanisms
for
each
subject,
type
that
we
define.
There
are
some
mechanisms
out
there
already
open
ID
connect
gives
us.
You
know
open
ID,
connect
discovery
that
you
know
it's
a
discovery
mechanism
off
issuer
and
subject.
It
also
talks
about
doing
that
discovery
off
of
email
address.
There
are
some
further
proposals
in
that
space
around
other
ways
to
do
that.
Discovery,
mobile,
the
open,
ID,
open,
ID
mobile
connect
group
also
has
some
pieces
in
place
for
discovering
from
phone
number
as
well
go
ahead.
Kathleen.
J
H
Think
privacy
concerns
are
definitely
something
that
the
working
group
has
spent
a
lot
of
time.
Talking
about
that's
one
of
the
big
concerns
is:
how
do
we
get
users
the
benefit
of
this
information
sharing
without
creeping
them
out,
because
we
don't
do
that
I'm
not
familiar
with
the
RFC
you
specified,
but
if,
if
you
have
input
you
want
to
provide
would
definitely
be
be
interested
to
hear
it
be
happy
to
talk
to
you
about
that
after
the
session,
since
it's
more
risk
oriented
yeah.
I
C
H
Is
is
giving
context
to
all
of
these
things
that
we're
saying
oh
profiles
will
do
it
profiles
will
do
it
well,
what
does
that
actually
mean?
What
does
that
actually
look
like
this
is
an
example
of
that.
Nevertheless,
I'd
be
happy
to
I'd
love
to
talk
to
you
after
words,
if
there's,
if
there's
information
or
guidance
at
a
ETF
has
learned
about
at
this
area
that
maybe
we
could
take
and
use
over,
there
that'd
be
great
to
hear
yeah.
J
J
I
H
Right,
one
of
the
other
things
we've
discussed-
I
didn't
show
it
here,
except
the
use
case.
Isn't
that
strong
was
communicating
via
hashes
of
identifiers
rather
than
the
identifiers
itself
that
be
particularly
valuable
in
scenarios
where
the
two
parties,
maybe
there's
less
clarity
over
whether
or
not
this
user
is
already
using
that
identifier
with
that?
Second,
with
that
other
party,
so
using
communicating
using
hashes,
will
give
you
that
sort
of
capability.
H
B
D
Shared
previously
in
the
case
of
open
ID
connect
through
the
ID
token,
so
risk
may
be
sharing
PII,
but
it's
data.
That's
previously
been
shared,
so
it's
not
exposing
new
information
and
but
we
actually
I
think
in
most
cases
are
trying
to
figure
out
still
can
we
actually
share
less
information
than
was
originally
disclosed
because
the
security
system
might
not
have
been
part
of
that
original
Federation.
J
H
F
F
It's
part
of
the
event
so
is
sub,
which
is
why
we
shouldn't
be
using
that
sub
up
there
I've
made
that
point
the
whole
time
I
think
that's
a
dumb
idea
too.
So
the
the
the
sub
that's
in
the
root
is
the
subject.
You
know
from
the
view
of
the
issuer
of
the
event,
not
necessarily
of
the
event
itself,
which
is
why
any
subject
to
the
event
should
be
in
the
event:
object.
Yeah.
H
Generally
within
risk,
you
know
that's
the
same
thing,
the
the
subject
from
the
perspective
of
the
transmitter
and
receiver
they're
identified
the
same
way.
Otherwise
you
don't
have
a
functional
system.
So
that's
the
way.
We've
approached
it,
but
if
that's
you
know,
contrary
to
what
is
being
mandated
at
by
the
set
spec,
then
there
isn't
really
a
problem
for
risk
to
move
that
down
into
the
event
body
itself.
Okay,.
I
F
H
F
C
H
H
H
C
D
Think
there's
I
mean
if
we
have
another
mysterious
draft
comes
from
somewhere
else.
They
may
be
talking
about
the
same
entity
that
would
be
implied,
even
though
they
have
different
subject:
terminology
for
them.
So,
for
example,
scheme
uses
URIs
for
resources,
yet
they
may
still
have
a
connect
subject
in
an
email.
So
there's
three
different
ways
to
talk
about
the
same
subject,
and
so
it
might
be
reasonable
to
have
you
know
in
payment
card
industry
using
credit
card
numbers.
So
it
might
be
reasonable
that
the
payment
card
payload
contains
the
credit
card
number.
D
C
Up
Krang
Kathleen's
point
around
privacy
right
with
multiple
events
all
tied
together,
we're
now
creating
a
bunch
of
correlated
identifiers,
is
on
the
same
user
and
saying
that
this
is
all
the
same
user.
Where,
if
you
had
different
events,
you
wouldn't
know
that
they're
necessarily
correlated
unless
you
already
have
that
correlated
data
correct.
H
D
I
guess
playing
devil's
advocate,
I
was
thinking
about.
If
you
send
them
separately,
then
the
left
hand
doesn't
know
what
the
right
hand
is
doing
and
I'm
not
sure
that
that's
always
a
good
thing
when
the
left
hand
and
the
right
hand
have
to
communicate.
At
the
same
time,
then
it's
clear
what
you're
communicating
as
an
organization
when.
H
When
they
have
to
communicate,
then
the
the
receivers
that
need
to
do
that
can
build
systems
to
do
that.
But
if
the
format
requires
or
mandates
that
the
information
gets
correlated,
then
the
receivers
who
don't
want
it
correlated
their
their
hands
are
tied.
They
don't
have
a
path
forward.
For
that.
The
other
thing
I
wanted
to
bring
up
about
putting
subject
in
the
event.
D
H
H
D
D
H
D
D
Along
so
first,
I
thought
I
addressed
the
question.
Why
skim?
When
I
looked
at
the
requirements
it
looked
awfully
familiar
skim
as
a
provisioning
protocol.
It
was
meant
to
provision
users
and
security
subjects.
It's
actually
been
used
quite
widely
and
extended
to
Internet
of
Things
provisioning
applications.
Lots
of
other
areas.
D
Skim
is
a
restful
design
that
defines
a
resource
lifecycle
and
one
of
its
key
points
is
maintaining
referential
integrity.
So,
as
things
change
over
time,
you
don't
lose
your
references
to
objects.
If
you
were
trying
to
remember
them,
this
was
a
problem
with
other
protocols
such
as
LDAP.
Another
thing
that
we
were
quite
concerned
about
some
of
those
features
seemed
useful
here.
It
has
some
good
implementation
and
open
source
availability.
If
you
want
to
look
for
a
list
of
those,
you
can
go
to
simple
cloud
info.
D
There
are
a
list
of
skim
one
and
skin
two
implementations
and
I
recently
checked,
and
there
are
over
20
skim.
Two
libraries
available
now
yeah
go
on
the
next
slide,
so
it's
widely
used
I'll
leave
that
for
later
we
have
the
same
design
requirements.
Let's
go
on
so
these
examples,
I'm
going
to
give
you
cover
off
both
risk
and
skim.
In
fact,
they're
mostly
risk.
One
of
the
key
differences
is
that
skim
uses
the
HTTP
methods
in
the
restful
sense
to
to
create
the
operations
to
create,
search,
replace,
modify
and
remove
a
resource.
D
So
one
of
the
fundamental
differences
Marius
was
showing
you
was
that
when
you,
for
example,
want
to
remove
a
subject,
it's
more
like
you're
passing
a
parameter
saying
this
is
the
subject:
I
want
to
remove
in
skim.
You
have
to
know
the
resource
of
that
subject
to
pull
it.
So
that's
a
bit
of
a
trade
off,
but
there
are
some
advantages
where
the
receiver
can
keep
track
of
the
subjects
it's
registered
and
delete
them
on
request.
D
If
it
wants
to
skim,
uses
JSON
documents
as
the
resources,
the
structure
of
those
documents
is
defined
by
RFC
76
43.
It
already
has
things
defined
like
attribute
types
mutability
marius
was
talking
about.
Is
a
configuration
attribute
read-only
or
is
it
updatable?
Is
it
right
only
things
like
that
skim
defines
how
you
handle
composites.
The
example
Annabelle
gave
about
subjects
being
either
a
Kinect
user
or
an
email
address.
That's
something
familiar
to
skim.
It
also
deals
with
attributes
that
may
be
visible
or
not
visible.
D
D
It
also
has
an
extension
mechanism,
so
if
I
was
defining
an
event,
stream,
I
could
use
that
extension
mechanism
to
define
and
a
place
to
put
configuration
parameters
for
each
delivery
method
that
gets
defined
over
time.
So,
let's
go
to
the
next
slide
in
order
to
figure
out
what
things
are
available
in
a
server.
What
event
streams
are
there?
There
is
discovery
to
find
out.
Where
is
the
container
for
event
streams?
D
D
D
Service
Rider,
config,
really
just
says,
tells
you
what
features
are
available
at
that
skin
endpoint
in
skin.
Certain
methods
are
optional
to
implement.
This
is
how
you
find
that
out
next
slide,
so,
like
Marius
showed,
we
have
defined
air
conditioning
handles
so
rather
than
get
into
that,
I
will
say
one
point
in
the
processing
rules.
D
We
work
hard
not
to
throw
errors.
The
issue
is,
if
you
understand
what
the
client
wants
to
be
done,
you
don't
necessarily
have
to
throw
the
error.
So
if
the
client
makes
a
mistake
by
trying
to
update
an
attribute,
that's
read
only
if
you
feel
that
you
understand
what's
going
on,
you
can
accept
that
not
throw
an
error.
This
gets
around
complex
problems
where
a
client
seems
to
think
a
parameter
is
writable,
but
it's
not
the
real
reason
for
it
was
we
wanted
to
be
able
to
do.
D
C
C
D
D
So
the
create
is
just
a
post
to
the
event
streams
endpoint.
This
is
we're
saying
that
I'm
creating
an
event
stream
and
I'm,
also
creating
an
extension
called
web
callback.
The
parameters-
these
would
be
the
standard
parameters
that
we
would
define
in
the
second
inspect
for
configuration
and
then
down
here
we
could
put
method
methods,
specific
configuration
parameters,
since
this
was
a
late.
Add
I
didn't
actually
give
a
full
example
of
a
delivery
method,
specific
parameters,
but
this
is
how
it
would
look
under
skin
next
slide.
D
So,
in
response
to
that,
you
get
an
object
created,
it
gets
a
permanent
resource
identifier,
some
long
gooood.
Basically,
that
number
is
the
same
here
as
marius
shown.
We
have
the
event
URIs
that
were
requested
the
event.
You
are
eyes
that
are
available,
that
the
service
provider
supports,
and
these
are
the
event,
your
eyes
that
are
configured
you'll
notice,
the
square
brackets,
which
tells
you
that's
an
array.
I
just
didn't,
have
multiple
examples
for
this
one.
So.
C
D
So
the
example
there,
if
I,
want
to
get
it
if
I
remember
that
URL
I
just
do
it
get
I
can
also
do
it
as
a
filtered
query
and
I
just
want
to
check
I
just
want
to
return
the
status
if
it's
not
equal
to
on.
If
it's
another
condition,
I
want
to
see
the
error
condition
and
what
happened
return
it
if
there
is
an
error.
D
So
in
this
example
we
got
the
we've
got
the
response
back.
The
status
wasn't
equal
to
okay.
It's
now
fail
and
there's
a
couple
of
attributes
here
to
signal
what
what
the
error
condition
was:
that's
preventing
the
event
delivery,
oh
bakwin's
line.
You
may
notice
that
there's
this
block
here,
which
is
metadata
in
skim
anytime,
you
see
that
that's
really
stuff.
That
says
when
was
the
record
last
modified
or
last
updated
that
kind
of
stuff?
That's
that's
what
I
mean
by
skin
meta
attributes.
D
So
this
is
something
that
was
difficult
to
decide
on
when
the
skin
group
was
doing
it.
It
wasn't
initially
liked
we
like
to
put
better,
but
over
time
this
has
become
the
favorite
method
for
updating
any
resource,
and
the
idea
is,
you
say:
I
want
to
replace
an
attribute
that
the
attribute
I
want
to
replace
his
status
and
its
new
value
is
paused.
D
Similarly,
just
do
a
put
and
having
previously
got
the
skin
the
configuration
of
the
event
stream
I
could
change
the
value
of
status
and
just
put
it
back,
that's
the
other
way
to
do
it.
Skin
doesn't
care.
You
can
work
either
way.
So
now
we're
into
the
the
risk
part
of
the
presentation.
In
the
skin
case,
we
tend
to
use
groups,
we
tend
to
use
filters
because
the
user
objects
are
actually
part
of
the
skin
server.
D
So,
in
the
event
steam
configuration
in
the
draft
you'll
see
there's
a
bunch
of
ways
to
configure
that
in
the
event
stream
configuration
but
I'll
give
you
a
few
examples
of
how
a
profile
such
as
risk
could
do
handle
the
use
case.
Like
subject
management.
Other
profiles
could
use
skim
in
a
different
way.
What
we're
trying
to
show
here
is
the
extensibility
that
skin
has
built
into
it
to
do
it
in
different
ways.
So.
D
C
C
D
D
D
D
Okay,
so
this
models
somewhat
similar
to
Maris's
primeras
in
Annabelle's
presentation,
where
we
do
a
post
to
an
endpoint
and
I,
provide
the
email,
the
stream
ID.
And
this
because
it's
skim,
you
have
to
say
what
is
the
object
that
you're
sending
so
that's
there.
I
would
just
specify
that
in
which,
in
response,
it
would
say
great
I've
created
that
so
this
subject,
enrollment
in
that
stream
becomes
a
permanent
object
that
can
be
referenced.
You
can
update
that
you
can
delete
it.
D
D
Just
decided
to
put
it
as
a
top-level
object,
you
could
also
say
stream.
Ids
is
plural,
so
I
can
enroll
a
single
subject
in
multiple
streams.
If
that's
what
I
wanted
to
do
like
to
delete
the
subject,
you
would
just
do
an
HTTP
delete
on
that
resource
identifier.
The
downside
is,
you
have
to
know
what
that
identifier?
That
path
is,
if
you
don't
know
it,
you
can
query
for
it
using
it
get
and
get
that
identifier.
So.
C
D
This
is
one
of
the
this
looks.
It's
simpler
from
the
standpoint
of
the
HTTP
operation
is
simple
because
of
the
life
cycle
issue.
You
end
up
having
to
create
a
permanent
resource
identifier,
so
it's
one
of
the
downsides
to
this
particular
model,
but
I
wanted
to
show
it
because
it
runs
in
parallel
to
Marius
and
Annabelle's
design
next
slide.
C
D
Is
all
I'm
trying
to
do
here
is
show
you
how
you
query
for
the
subjects
we're
still
talking
about
the
subjects
object.
How
do
I
query
and
say
what
is:
is
this
example
user
part
of
this
stream?
So
there's
how
you
would
express
that
filter
and
get
that
back
and
a
similar
thing
where
issuer
is
gmail.com
and
the
subject
equals
independent
ID
expressed
a
different
way
next
slide.
D
So,
if
I
want
to
check
that
a
particular
subject
is
part
of
a
stream
I
can
I
can
ask
this
the
query,
and
that
tells
us
there's
no
match
if
there's
no
match
I
get
total
results
equals
zero.
If
I
go
to
the
next
slide
and
I
can
get
a
match,
it
says
there
is
one
match
and
the
ID
of
the
stream
that
matches
is
here.
The
reason
I'm
only
getting
ID
is
that
I
only
wanted
the
attribute,
ID
returned,
so
I
don't
have
to
eat
the
whole
elephant.
D
So
this
is
an
example
of
how
I
would
confirm
that
an
open,
ID
Connect
subject
is
part
of
a
stream.
What
the
complication
that
open
ID
Connect
presents
is
that
it's
a
two-part
subject,
you
have
to
have
both
issuer
and
subject
and
in
a
database
you
can
end
up
with
inner
outer
join
problems.
So
the
way
skin
resolves
this
is
by
saying
subjects.
D
Is
the
parent
attribute
and
I
want
to
do
a
filter
against
on
the
same
record
if
value
equals
this
and
issue
or
equals
this
then
I'll
get
the
correct
intersection
on
the
correct
value
of
subjects.
Will
work
so
that
avoids
nasty
inner
outer
join
problems,
so
that
seems
complex,
but
it's
not
because
the
protocol
is
complex.
It's
because
the
problem
is.
D
D
Is
that
clear,
just
a
couple
more
so
if
I
want
to
add
a
subject,
Alice
at
example.com
to
the
stream
configuration
I'm,
updating
the
subjects
attribute
and
the
value
is
got
two
sub
attributes
type
and
value,
and
that's
how
you
add
somebody
to
a
stream-
and
this
is
the
same
example
done
for
open
ID
connects
of
the
type
is
open,
ID
Connect,
so
the
value
this
is
an
open,
ID,
Connect,
subject
value
and
the
issuer.
Yes,
we
complete
information
so.
C
D
I
C
D
H
D
That's
just
how
skim
expresses
it
and
how
discovery
of
configuration
is
done.
So
when
you
have
a
new
transmission
method
come
along,
you
would
be
able
to
find
out
if
that
service
provider
supports.
We
talked
about
polling
just
a
few
minutes
ago.
If
you
want
to
know,
does
Amazon
support,
polling
I
could
check
the
schemas
thing
to
see
if
you
have
that
defined
the.
D
B
B
D
D
Origins
started
as
an
informal
SPECT
under
skin
one
that
Salesforce
started
with
paying
in
a
few
other
companies,
and
it
was
formalized
a
few
years
later
as
skim
to
so
that's
where
it
came
from
so
and
as
I
recall,
that
would
have
predated
blockchain
by
a
long
time
so
I
possible
it's
just
a
coincidence
or
possible.
They
took
some
of
the
model
from
skin.
D
Skin
is
one
of
the
perspectives
here.
You
make
a
good
point
because
one
of
the
perspectives
when
we
were
starting
stock
events
and
yarns
brought
it
up
over
and
over,
is
why
don't
you
use
an
existing
protocol
for
managing
this
stuff?
Like
Netcom,
my
answer
was:
we
are
reusing
a
protocol.
It's
called
skin
because
many
of
us
are
also
skin
users
as
well,
but
net
comp
to
the
people
who
are
interested
would
be
brand
new
to
everyone.
B
D
The
problem
I
think
comes
up
is
that
for
the
skin
community
any
change
means
an
additional
protocol.
They
have
to
support
so
I'll
admit
it's
a
shortcut
for
the
skimming
community,
because
we
don't
have
to
do
anything
new.
We
already
have
it
but
I
know.
There's
lots
of
people
in
the
room
who
are
a
risk.
You're,
saying
skins
new
to
me
and
I
have
to
implement
that
skim,
stack
and
I
don't
want
to
so
they
might
be
just
as
equally
amenable
to
net
comp
for
something
brand
new
I
thought.
That's
news.
B
H
Yeah,
just
briefly
to
that
point:
it's
not
necessarily
our
problem,
but
it's
the
problem
of
the
people
who
are
ultimately
going
to
have
to
implement
these
things
and
play
with
this
Interop.
If
we
want
these
protocols
to
be
adopted,
then
they
have
to
be
at
least
four
risk,
or
we
need
something.
That's
going
to
be
easy
for
the
long
tail
of
parties
out
there
to
implement
yeah.
D
C
Well,
it's
always
relative,
if
you've
already,
if
you
already
got
skim,
deployed
and
running
it
so
I'm
on
my
slides
now,
which
you
chewed
in
ten
minutes,
you
ten
ten
ten
minutes
into
my
slides,
so
just
Phil
had
this
and
the
profiles
before
that.
We
have
a
bunch
of
different
profiles
and
you
know
as
I
look
at
a
lot
of
the
traffic
on
the
list.
C
J
They
have
several
profiles
that
have
to
be
compared
to
see
what
they
want
to
prioritize
to
move
forward
and
there's
all
different
requirements
and
use
cases
that
would
feed
each
of
those,
as
well
as
interest
in
implementing
and
deploying
right
to
understand
how
to
prioritize
and
and
what
should
be
worked
on
and
they're
doing
that
on
the
wiki
of
the
working
group,
every
working
group
has
a
wiki.
Is
there
something
here
where
you
could?
It
could
even
just
be
a
session
or
interim
where
you
run
through
these
priorities
doesn't
have
to
be
wiki.
C
I
C
D
Before
you
launch
into
that
I'm,
not
so
sure
it's
a
question
of
overlap
between
skin
versus
heart
versus
risk.
What
I
am
sensing,
at
least
from
my
perspective,
is
the
the
square
peg
round
hole
issue
it
has
to
do
with
enterprise
versus
consumer
within
the
risk
space.
So
risk
is
not
as
doesn't
have
as
strong
as
consensus
at
this
time,
as
maybe
it
should,
and
that's
bleeding
over
into
this
working
group,
as
as
to
trying
to
lay
the
foundation
requirements
that
cover
them
all.
Yes,.
C
C
It
doesn't
seem
like
we
have
strong
consensus
within
second
aunt,
and
some
of
that
may
be
the
lack
of
strong
consensus
within
risk,
so
just
what
some
of
those
open
issues
on
set,
there's
sort
of
the
singularity
and
plural
our
reality
of
events
on
the
subject.
Where
is
the
subject?
How
does
that
work?
There
seems
to
be
a
fair
amount
of
contention
around
those
aren't,
set
delivery,
there's
push
versus
pull
and
then,
as
as
Mary's
brought
in
there's,
do
we
specify
how
you
attend
occation
happens,
or
is
that
left
to
the
profile?
C
C
C
You
know
so
the
you
know
question
I
have.
Is
there
enough
overlap
across
all
of
this
stuff?
You
know
and
what
are
the
next
steps
on
these
different
things?
You
know
there's
contention
onset
event.
Distribution
seems
to
be
a
little
more
aligned,
but
there's
you
know,
pull
versus
push,
you
know.
Should
those
be
separate
documents?
Does
that
even
useful
enough
to
do
those?
There
definitely
seems
to
be
two
completely
different
ideas
on
the
management
API
and
to
Justin's
earlier
question.
C
You
know
so
I
sort
of
have
these
open
questions
that
I'm
posing
to
the
working
group
and
welcome
people
to
come
up
and
provide
commentary
on
their
thoughts
on
this
and
would
love
guidance
from
the
ADR.
And
how
do
I
drive
consensus
where
there
isn't
I,
don't
know
if
it
makes
sense
for
there
to
be
consensus
for
some
things.
F
This
is
Justin
I
would
encourage
all
the
members
of
the
working
group
to
concentrate
on
the
commonalities
between
different
profiles
and
specifying
those
instead
of
waging
wars
over
oh
I
have
my
little
special
snowflake
attribute
over
here.
That
I
really
really
really
need
to
have.
Okay,
that's
fine.
Go
have
that
I,
don't
care
figure
out
where
the
overlaps
are
right,
figure
out
what
those
round
pegs
actually
are
that
do
belong
in
the
second
vent.
F
I
do
think
that
there
are
quite
a
number
of
them
that
we
could
agree
on
time
of
event
being
a
really
simple
one
that
seems
to
have
bubbled
up
surprisingly
recently,
and
that
I
believe
is
where
we're
going
to
start
seeing
driving
consensus
towards
something
that
these
multiple
groups
and
multiple
profiles
and
whatever
can
actually
use
the
discussions
that
I've
seen
on
the
list
in
this
group
so
far
have
largely
been
around
people.
Arguing.
No,
don't
specify
that
because
I
need
something
else
or
I'm
going
to
do
something
else
or
I.
F
H
H
Annabelle
Backman
so
I
definitely
agree
with
Justin
on
focusing
on
the
yeah
the
actual
round
pegs
your
description
of
what's
been
going
on
at
the
very
end,
though,
about
people
saying
no,
don't
specify
that
because
that
doesn't
work
for
me
or
don't
specify
facts.
I
need
to
do
something
different.
That
sounds
more
like
a
disagreement
over
what
is
a
round
peg
and
what's
not
so
if
we
haven't
even
gotten
consensus
around
that
I
think
it's
hard
to
you
know
focus
on
the
round
pegs,
if
you
know
we're
we're
all
seeing
them
differently.
G
C
They
all
work
sure
yeah
I
mean
when
you,
when
you're
sitting
there
with
a
hammer,
everything
looks
like
a
nail
yeah
but
I.
Think
that's.
Some
of
the
challenge
in
the
group
is
some
people
come
from
up
one
side
and
it
all
makes
sense
of
them
and
other
people
come
from
another
angle
and
they
have
quite
a
different
view
on
what
are
the
right
tools.
J
C
Guidance,
R
and
I.
Almost
every
one
of
the
documents
has
a
fair
amount
of
contention
on
it
and
you
know,
as
I
have
listened
to
the
different
sides.
You
know
different
people
have
valid
points
for
what
they're
trying
to
do,
because
we're
trying
to.
We
have
a
number
of
different
use
cases
all
trying
to
use
the
same
thing,
but
maybe
they
don't
really
all
fit
because
like
one's
a
screw
and
one's
a
nail-
and
you
should
use
a
screw
driver
versus
a
hammer-
yes
I
know
that's
right.
J
J
C
J
C
J
J
J
C
J
H
Annabelle
Backman
I
think
from
what
I've
seen
on
the
list.
Most
of
her
more
of
the
disagreement
and
contention
is
around
the
protocol
aspects,
the
in
the
api's,
rather
than
the
set
token
format
itself,
not
that
there's
hasn't
been
contention
there,
but
I
think
it's
relatively
minor
in
comparison.
It
seems
to
me
that
if.
H
The
points
that
there's
contention
over
I
think
arise
less
from
your
technical
incompatibility
issues,
whereas
in
the
the
protocol
space
we
have,
you
know
one
party
saying
well,
we
have
something
that
works
and
we
don't
want
to
do
something
else
and
other
parties
saying
well
the
option
that
works
great,
for
you
doesn't
work
great
for
us.
That's
sort
of
more
of
a
fundamental
disagreement
over
over
requirements,
because
I
think
at
the
token
format
level
there
isn't
as
much
of
that,
but
if
we
can't
close
on
the
open
issues.
H
D
Think
the
issue
is,
is
that
for
many,
the
o3
draught
has
a
certain
wide
utility
that
can
be
used
in
many
way
and
Annabelle
and
yourself
would
like
to
strict
it
and
now
Justin
would
like
to
restrict
it
to
one
event:
payload
and,
and
one
only
so
there
is
a
lot
of
commonality
and
that
we
want
to
convey
at
least
one
event,
but
the
problem
becomes,
for
those
of
us
at
the
end
of
the
day,
have
to
convey
multiple
components
to
that
message.
That
just
shifts
the
complexity
somewhere
else.
D
Now
we're
talking
about
a
more
complex
delivery
protocol,
a
bunch
of
things
all
follow
from
that
or
we
walk
away,
and
we
don't
have
second
ents
anymore.
I,
still
maintain
that
the
o3
draught
can
be
deployed
and
used
in
a
single
event
way
quite
easily,
and
the
message
is
clear
and
the
message
is
quite
simple:
it
only
starts
to
look
complex
for
these
edge
cases
where
you
need
to
have
multiple
payloads
and
you
can't
it's
it's
an
optional
part
and
people
don't
have
to
use
it.
It
can
be
used
in
a
very
simple.
C
D
C
D
Phil
Phil
here
think
the
example
you're
referring
to
was
risks.
Analysis
of
this
and
I
have
to
point
out
that
the
risk
working
group
hasn't
agreed
that
conveying
one
event
URI
is
appropriate
there
at
all.
We
don't
agree
there,
so
we
don't
agree
here.
Sure
say
that
risk
analyzed
it
and
came
to
that
conclusion
would
be
a
mischaracterization
people.
C
D
G
You
know
other
ideas
have
come
into
this
group,
all
you
know
into
into
this
working
group,
since
it
got
formed
based
upon
the
skin
work
and
so
yeah
so
things.
Yes,
sorry,
I'm
talking
you
mine,
geez,
that's
really,
and
so
the
you
know
some
of
the
people's
thoughts
are
just
you
know
different
than
what
it
all
started
out
to
be.
You
know,
and
you
know
some
of
we
use
this
for
both.
G
C
I
A
My
disco,
disco
I
just
want
to
highlight
the
fact
that
the
proposals
to
simplify
the
set
comes
from
two
companies
who
are
actually
doing
an
actual
implementation
right
now.
So
this
is
feedback
after
implementing
this
and
deploying
these
things
and
it's
early
feedback
from
implementation.
We
are
keeping
owning
that
that's
gonna
come
up
as
more
people
implement
this
and
yeah.
That's
what
I
want
to
say
thanks
yeah.
F
John
Bradley
yubico
so
way
back
in
the
dark
days
when
there
was
a
skin
working
group.
Still
there
was
a
conversation
that
happened
between
the
Open
ID
Connect
working
group,
which
needed
to
do
a
back-channel
logout
ie
send
a
shot
from
the
identity
provider
to
the
relying
party
to
say
this.
Login
has
been
revoked,
terminate
the
session
and
we
said,
looked
around
and
said.
Well,
we
could
just
send
an
ID
token
with
an
additional
claim,
saying
logout
seems
simple
enough,
but
then
we
had
a
I
had
a
conversation
with
life.
F
When
we
said
you
know,
maybe
there's
some
combination.
You
know
we
shouldn't
necessarily
try
and
do
something
separate,
there's
already
a
control
channel,
that's
happening
back
using
skim.
Is
there
some
way
that
we
could
use
skins
using
skim
itself
turned
out
to
be
way
more
complicated
than
anybody
was
interested
in
deploying?
So
then
we
started
well.
What
about
the
skin
messaging
thing
that
hasn't
hadn't
really
caught
on
at
that
point,
then
other
people
have
piled
on,
but
well
well,.
C
F
C
F
C
F
My
point
is
that
we
have
attempted
to
work
together
if
you
know,
as
as
this
workgroup
has
sort
of
taken
off
what
largely
happened
is
that
sat
has
gotten
so
complicated
with
the
management
API.
It
may
not
actually
be
plausibly
deployable
as
an
open
ID
connect,
back-channel
logout
mechanism,
because
no
one
is
going
to
be
willing
to
deploy
all
of
the
extra
functionality
which
I
think
some
of
the
point
that
Ana,
belén
and
others
are
trying
to
make.
So
it
may
actually.
C
Thank
you
we're
out
of
time.
Thank
you.
Everybody
I
will
work
to
create
a
doc
on
what
I
think
ours,
where
we
have
common
agreement
to
see
how
much
that
is
and
post
that
to
list
and
we'll
have
discussion
on
the
list.
We'll
also
see
if
we
can
have
some,
maybe
an
ad
hoc
meeting,
posted
and
I'll
post
on
a
list
or
later
this
week
to
keeping
driving
to
some
of
this
more.