Subject: [Id-event] Proposal for Identity Event Standard

From: Sarah Squire <[email-masked]>
Date: Mon, 1 Feb 2016 09:35:56 -0800

Hi all,

I’ve been mulling the idea of identity events and have run into several
situations with different clients where they could be useful. I have a
strawman that I would love for you all to take a few torches to.

I propose that we create a new standard for a JSON Web Log, or JWL.

The problem I’m running into is that in distributed access management
protocols like OAuth and UMA, different ecosystem parties are often in
different security domains and have no language to talk to each other
outside of prescribed transactions. There are many cases in which only one
party has a log of an identity event, and it would be helpful if they had
some way to transmit that log to other parties in the ecosystem.

Here is a list of a few things that a relying party might want to say to an
identity provider:

   -

   This user’s behavior is inconsistent with past heuristics and I suspect
   fraud
   -

   the RP did parallel authentication of a second factor (e.g. My employee
   Susan has verified that this user matches (or does not match) the photo on
   file at the IdP)
   -

   Here is a privacy policy that this user consented to

Here is a list of a few things that an identity provider might want to say
to a relying party:

   -

   This user’s email changed since the last time you called the UserInfo
   endpoint
   -

   A user account we have authenticated for you in the past has been
   compromised
   -

   This user has revoked your access token

My proposal is that a JWL standard be developed based on the form of a JWT,
though with some different fields. It should require iss, sub, aud, and
iat, and the optional fields I think would fall into four categories:
suspected fraud, userinfo update, consent information, and parallel
authentication. Both RPs and IdPs would implement a JWL endpoint to receive
JWLs from other members of the ecosystem.

Thoughts? Would this be helpful?

Sarah

Sarah Squire
Engage Identity
http://engageidentity.com

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 1 Feb 2016 20:00:54 +0100

It makes sense what you write, Sarah.

I believe you might find this work in the OpenID Foundation relevant to
your ideas:
http://openid.net/wg/risc/

Ciao
Hannes

On 02/01/2016 06:35 PM, Sarah Squire wrote:
> outside of prescribed transactions. There are many cases in which only
> one party has a log of an identity event, and it would be helpful if
> they had some way to transmit that log to other parties in the ecosystem.
> 
> 
> Here is a list of a few things that a relying party might want to say to
> an identity provider:
> 
> 
>   *
> 
>     This user’s behavior is inconsistent with past heuristics and I
>     suspect fraud
> 
>   *
> 
>     the RP did parallel authentication of a second factor (e.g. My
>     employee Susan has verified that this user matches (or does not
>     match) the photo on file at the IdP)
> 
>   *
> 
> Here is a list of a few things that an identity provider might want to
> say to a relying party:
> 
> 
>   *
> 
>     This user’s email changed since the last time you called the
>     UserInfo endpoint
> 
>   *
> 
>   *
> My proposal is that a JWL standard be developed based on the form of a
> JWT, though with some different fields. It should require iss, sub, aud,
> and iat, and the optional fields I think would fall into four
> categories: suspected fraud, userinfo update, consent information, and
> parallel authentication. Both RPs and IdPs would implement a JWL
> endpoint to receive JWLs from other members of the ecosystem.
> 
> 
> http://engageidentity.com <http://engageidentity.com/>
> 
> 
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>

---

From: John Wunderlich <[email-masked]>
Date: Mon, 1 Feb 2016 14:56:52 -0500

Sarah;

Are you replicating the problem of “..no language to talk to each other outside of prescribed transactions” at a higher level by prescribing a set of four categories? It seems an appropriate solution to the cases you describe, but are there other cases that would necessitate additional categories? When I read the first part of your strawman, I thought your reference to a JSON Web Log was starting down the road to a distributed database (must still have blockchain on my mind from the last IIW). Or am I misunderstanding and is what you are proposing a semantic solution to the problem you pose?

Sincerely,
John Wunderlich
(@PrivacyCDN)

 <http://privacybydesign.ca/> <http://privacybydesign.ca/>

 <http://privacybydesign.ca/>Privacist & PbD Ambassador <http://privacybydesign.ca/>

> On Feb 1, 2016, at 12:35, Sarah Squire <[email-masked]> wrote:
> 
> Hi all,
> 
> I’ve been mulling the idea of identity events and have run into several situations with different clients where they could be useful. I have a strawman that I would love for you all to take a few torches to.
> 
> The problem I’m running into is that in distributed access management protocols like OAuth and UMA, different ecosystem parties are often in different security domains and have no language to talk to each other outside of prescribed transactions. There are many cases in which only one party has a log of an identity event, and it would be helpful if they had some way to transmit that log to other parties in the ecosystem.
> 
> Here is a list of a few things that a relying party might want to say to an identity provider:
> 
> This user’s behavior is inconsistent with past heuristics and I suspect fraud
> the RP did parallel authentication of a second factor (e.g. My employee Susan has verified that this user matches (or does not match) the photo on file at the IdP)
> Here is a list of a few things that an identity provider might want to say to a relying party:
> 
> This user’s email changed since the last time you called the UserInfo endpoint
> A user account we have authenticated for you in the past has been compromised
> My proposal is that a JWL standard be developed based on the form of a JWT, though with some different fields. It should require iss, sub, aud, and iat, and the optional fields I think would fall into four categories: suspected fraud, userinfo update, consent information, and parallel authentication. Both RPs and IdPs would implement a JWL endpoint to receive JWLs from other members of the ecosystem.
> 
> http://engageidentity.com <http://engageidentity.com/>_______________________________________________
> Id-event mailing list
> [email-masked]

-- 

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.

---

From: Sarah Squire <[email-masked]>
Date: Mon, 1 Feb 2016 12:09:39 -0800

Hi John,

Good questions. I'm not proposing a distributed database or anything
blockchain-like. I am merely suggesting, as you say, that we add a few more
prescribed transactions and an endpoint for them to the existing standards.
These seem to be high-value communications that currently aren't happening
or are happening out of band in non-standardized communications.

There may well be additional categories. I'd be curious if other folks on
this list have more use cases that this standard could address.

Sarah

Sarah Squire
Engage Identity

On Mon, Feb 1, 2016 at 11:56 AM, John Wunderlich <[email-masked]> wrote:

> Sarah;
>
> Are you replicating the problem of “..no language to talk to each other
> outside of prescribed transactions” at a higher level by prescribing a set
> of four categories? It seems an appropriate solution to the cases you
> describe, but are there other cases that would necessitate additional
> categories? When I read the first part of your strawman, I thought your
> reference to a JSON Web Log was starting down the road to a distributed
> database (must still have blockchain on my mind from the last IIW). Or am I
> misunderstanding and is what you are proposing a semantic solution to the
> problem you pose?
>
> Sincerely,
> *John Wunderlich*
> *(@PrivacyCDN)*
>
> <http://privacybydesign.ca> <http://privacybydesign.ca>
>
>
> <http://privacybydesign.ca>Privacist & PbD Ambassador
> <http://privacybydesign.ca>
>
>
>
>
>    - This user’s behavior is inconsistent with past heuristics and I
>    suspect fraud
>    - the RP did parallel authentication of a second factor (e.g. My
>    employee Susan has verified that this user matches (or does not match) the
>    photo on file at the IdP)
>    - Here is a privacy policy that this user consented to
>
>
>    - This user’s email changed since the last time you called the
>    UserInfo endpoint
>    - A user account we have authenticated for you in the past has been
>    compromised
>    - This user has revoked your access token
>
>
> and iat, and the optional fields I think would fall into four categories:

---

From: John Wunderlich <[email-masked]>
Date: Mon, 1 Feb 2016 15:11:49 -0500

Thanks.

It sounds like a useful incremental improvement, as you say, but it does point to a more interesting general problem down the road.

Sincerely,
John Wunderlich
(@PrivacyCDN)

> On Feb 1, 2016, at 15:09, Sarah Squire <[email-masked]> wrote:
> 
> Hi John,
> 
> Good questions. I'm not proposing a distributed database or anything blockchain-like. I am merely suggesting, as you say, that we add a few more prescribed transactions and an endpoint for them to the existing standards. These seem to be high-value communications that currently aren't happening or are happening out of band in non-standardized communications.
> 
> There may well be additional categories. I'd be curious if other folks on this list have more use cases that this standard could address.
> 
> Sarah
> 
> Sarah Squire
> Engage Identity
> On Mon, Feb 1, 2016 at 11:56 AM, John Wunderlich <[email-masked] <mailto:[email-masked]>> wrote:
> Sarah;
> 
>> On Feb 1, 2016, at 12:35, Sarah Squire <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi all,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
> 
> 
> 
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
> 

--

---

From: Phil Hunt <[email-masked]>
Date: Mon, 1 Feb 2016 14:03:13 -0800

What we are working on new is a generic event system that has the following traits:

* Events (that may be extended for different purposes) that are based on JWT (JSON Web Token).
* JWT gives us the ability to have: plain text, signed, and/or encrypted events that may be transported over different protocols like HTTP or mobile messaging platforms.
* A RESTful publish and subscribe system where interested parties may register interest in certain event types.
* Many use cases are inter-domain notifications (e.g. RISC and SCIM events).  Others are events for things like mobile apps (a profile or subscription change).

The generic event spec should be extensible for Sarah’s case (if not I’d like to find out why). Though I would check in with the existing types to see if some of the groups like OpenID aren’t already covering something similar.

Phil

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

> On Feb 1, 2016, at 12:11 PM, John Wunderlich <[email-masked]> wrote:
> 
> Thanks.
> 
>> On Feb 1, 2016, at 15:09, Sarah Squire <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi John,
>> 
> <signature.asc>_______________________________________________
> Id-event mailing list

---

From: Luis SAIZ GIMENO <[email-masked]>
Date: Tue, 2 Feb 2016 09:47:56 +0100

I'm not an active member in the list but as a customer of this kind of
solutions having an standard way to emit/receive events from/to IdP/RP is
something that we'll appreciate a lot

Phil, how it's organized the work in progress you mention?

2016-02-01 23:03 GMT+01:00 Phil Hunt <[email-masked]>:

> * JWT gives us the ability to have: plain text, signed, and/or encrypted
> events that may be transported over different protocols like HTTP or mobile
> messaging platforms.
> * A RESTful publish and subscribe system where interested parties may
> register interest in certain event types.
> * Many use cases are inter-domain notifications (e.g. RISC and SCIM
> events).  Others are events for things like mobile apps (a profile or
> subscription change).
>
> The generic event spec should be extensible for Sarah’s case (if not I’d
> like to find out why). Though I would check in with the existing types to
> see if some of the groups like OpenID aren’t already covering something
> similar.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
>
>
> It sounds like a useful incremental improvement, as you say, but it does
> point to a more interesting general problem down the road.
>
> Sincerely,
> *John Wunderlich*
> *(@PrivacyCDN)*
>
>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they are
>> addressed. If you have received this email in error please notify the
>> system manager. This message contains confidential information and is
>> intended only for the individual named. If you are not the named addressee
>> you should not disseminate, distribute or copy this e-mail. Please notify
>> the sender immediately by e-mail if you have received this e-mail by
>> mistake and delete this e-mail from your system. If you are not the
>> intended recipient you are notified that disclosing, copying, distributing
>> or taking any action in reliance on the contents of this information is
>> strictly prohibited.
>>
>
>
>
>

-- 

*BBVA*

*Luis Saiz Gimeno*

*Innovation in Security*

Móvil +34 609703264 - Tel. +34 918073152 - [email-masked]

*Engineering - Architecture & Global Deployment *– Monforte de Lemos, s/n,
28029

Maps:
https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,+28,+28029+Madrid/

Antes de imprimir este mensaje, por favor comprueba que es necesario
hacerlo. Before you print this message please consider if it is really
necessary.

-- 

"Este mensaje está dirigido de manera exclusiva a su destinatario y puede 
contener información privada y confidencial. No lo reenvíe, copie o 
distribuya a terceros que no deban conocer su contenido. En caso de haberlo 
recibido por error,  rogamos lo notifique al remitente y proceda a su 
borrado, así como al de cualquier documento que pudiera adjuntarse.

 Por favor tenga en cuenta que los correos enviados vía Internet no 
permiten garantizar la confidencialidad de los mensajes ni su transmisión 
de forma íntegra.

 Las opiniones expresadas en el presente correo pertenecen únicamente al 
remitente y no representan necesariamente la opinión del Grupo BBVA."

 "This message is intended exclusively for the adressee and may contain 
privileged and confidential information. Please, do not disseminate, copy 
or distribute it to third parties who should not receive it. In case you 
have received it by mistake, please inform the sender and delete the 
message and attachments from your system.

 Please keep in mind that e-mails sent by Internet do not allow to 
guarantee neither the confidentiality or the integrity of the messages 
sent."

---

From: Mark Lizar - OCG <[email-masked]>
Date: Tue, 2 Feb 2016 09:03:52 +0000

Sarah,

I think it is terrific thinking and very insightful.  We are very interested in this for consent events and the delegation of consent for a wide array of access control notices and transactions which relate to consent records.  It appears work like this  would extend the core of the consent work we are doing and I think its very well timed, a super efficient and technically great approach to the set of problems in this space.

The JWT logging is brilliant :-)     Personally, I think the Consent and Information Sharing  WG would be very happy to see your work move in this direction and I would hope that we could compliment it.

Mark Lizar
Executive Director
Open Consent Group

Email: [email-masked]
Twitter: @smartopian

> On 2 Feb 2016, at 08:47, Luis SAIZ GIMENO <[email-masked]> wrote:
> 
> I'm not an active member in the list but as a customer of this kind of solutions having an standard way to emit/receive events from/to IdP/RP is something that we'll appreciate a lot
> 
> 
> 2016-02-01 23:03 GMT+01:00 Phil Hunt <[email-masked] <mailto:[email-masked]>>:
>> On Feb 1, 2016, at 12:11 PM, John Wunderlich <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Thanks.
>> 
> BBVA
> Luis Saiz Gimeno
> Innovation in Security
> Móvil +34 609703264 - Tel. +34 918073152 - [email-masked] <mailto:[email-masked]>
> Engineering - Architecture & Global Deployment – Monforte de Lemos, s/n, 28029
> Maps: https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,+28,+28029+Madrid/ <https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,+28,+28029+Madrid/>
> Antes de imprimir este mensaje, por favor comprueba que es necesario hacerlo. Before you print this message please consider if it is really necessary.
> 
> "Este mensaje está dirigido de manera exclusiva a su destinatario y puede contener información privada y confidencial. No lo reenvíe, copie o distribuya a terceros que no deban conocer su contenido. En caso de haberlo recibido por error,  rogamos lo notifique al remitente y proceda a su borrado, así como al de cualquier documento que pudiera adjuntarse.
> 
>  Por favor tenga en cuenta que los correos enviados vía Internet no permiten garantizar la confidencialidad de los mensajes ni su transmisión de forma íntegra.
> 
>  Las opiniones expresadas en el presente correo pertenecen únicamente al remitente y no representan necesariamente la opinión del Grupo BBVA."
> 
>  "This message is intended exclusively for the adressee and may contain privileged and confidential information. Please, do not disseminate, copy or distribute it to third parties who should not receive it. In case you have received it by mistake, please inform the sender and delete the message and attachments from your system.
> 
>  Please keep in mind that e-mails sent by Internet do not allow to guarantee neither the confidentiality or the integrity of the messages sent."
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 3 Feb 2016 17:52:18 -0500

I think this is a really great idea. It’s the kind of abstraction that the “ID Events” conversation was pointing towards initially, by my view. I actually see the JWL as the superset, since the events aren’t always “ID related”.

I think an important next step would be to start defining payloads for different use cases. Like:

 “I’m an RP and someone just deleted their account with me, I need to tell the IDP.”

 “I’m an AS and a user just revoked access to an app, I need to tell the app.”

 “I’m an AS and a user’s account was compromised, I need to tell all downstream apps to watch out.”

 “I’m an AS and a third-party account was used to access a user’s resources by their policy (think UMA), I need to record something and tell the user at their designated endpoint.”

What would each of these strawmen look like as JSON objects inside of a JWL? Can we start to extract common claims? I don’t think that JWT is necessarily going to be a good base, but it might be reasonable to start there. What’s the issuer, subject, and audience of each statement? How do we record the kind of action? Do we have an ontology or registry?

Lots of very important questions will start to fall out, and hopefully their answers too, once we start putting JSON to the page.

 — Justin

> On Feb 2, 2016, at 4:03 AM, Mark Lizar - OCG <[email-masked]> wrote:
> 
> Sarah,
> 
> Email: [email-masked] <mailto:[email-masked]>
> Twitter: @smartopian
> 
>> On 2 Feb 2016, at 08:47, Luis SAIZ GIMENO <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 3 Feb 2016 15:09:53 -0800

+1

Phil

> On Feb 3, 2016, at 14:52, Justin Richer <[email-masked]> wrote:
> 
>>>>> Privacist & PbD Ambassador
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>>> Privacist & PbD Ambassador
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>> Maps: https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,+28,+28029+Madrid/

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 4 Feb 2016 01:16:26 +0000

+1

I definitely like the idea of expanding the scope of “ID events”, but I think we still somehow need to somehow anchor it to a loose definition of identity where all identity related events are included but no worry about any type of events. I am a bit afraid of going beyond that might significantly slow down progress.

Cheers,
Morteza

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 3, 2016 at 3:09 PM
To: Justin Richer <[email-masked]<mailto:[email-masked]>>
Cc: Luis SAIZ GIMENO <[email-masked]<mailto:[email-masked]>>, John Wunderlich <[email-masked]<mailto:[email-masked]>>, Mark Lizar - OCG <[email-masked]<mailto:[email-masked]>>, Sarah Squire <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Proposal for Identity Event Standard

+1

Phil

On Feb 3, 2016, at 14:52, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 — Justin

On Feb 2, 2016, at 4:03 AM, Mark Lizar - OCG <[email-masked]<mailto:[email-masked]>> wrote:

Sarah,

Mark Lizar
Executive Director
Open Consent Group

Email: [email-masked]<mailto:[email-masked]>
Twitter: @smartopian

On 2 Feb 2016, at 08:47, Luis SAIZ GIMENO <[email-masked]<mailto:[email-masked]>> wrote:

2016-02-01 23:03 GMT+01:00 Phil Hunt <[email-masked]<mailto:[email-masked]>>:
What we are working on new is a generic event system that has the following traits:

Phil

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

On Feb 1, 2016, at 12:11 PM, John Wunderlich <[email-masked]<mailto:[email-masked]>> wrote:

Thanks.

Sincerely,
John Wunderlich
(@PrivacyCDN)

<http://privacybydesign.ca/><http://privacybydesign.ca/>

<http://privacybydesign.ca/>Privacist & PbD Ambassador<http://privacybydesign.ca/>

On Feb 1, 2016, at 15:09, Sarah Squire <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

Sarah

Sarah Squire
Engage Identity
http://engageidentity.com<http://engageidentity.com/>

On Mon, Feb 1, 2016 at 11:56 AM, John Wunderlich <[email-masked]<mailto:[email-masked]>> wrote:
Sarah;

Sincerely,
John Wunderlich
(@PrivacyCDN)

<http://privacybydesign.ca/><http://privacybydesign.ca/>

<http://privacybydesign.ca/>Privacist & PbD Ambassador<http://privacybydesign.ca/>

On Feb 1, 2016, at 12:35, Sarah Squire <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

  *

  *

Sarah

Sarah Squire
Engage Identity
http://engageidentity.com<http://engageidentity.com/>
_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
<signature.asc>_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

--
BBVA
Luis Saiz Gimeno
Innovation in Security
Móvil +34 609703264 - Tel. +34 918073152 - [email-masked]<mailto:[email-masked]>
Engineering - Architecture & Global Deployment – Monforte de Lemos, s/n, 28029
Maps: https://www.google.es/maps/place/Av.+de+Monforte+de+Lemos,+28,+28029+Madrid/
Antes de imprimir este mensaje, por favor comprueba que es necesario hacerlo. Before you print this message please consider if it is really necessary.

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

---

From: Ian Glazer <[email-masked]>
Date: Thu, 4 Feb 2016 10:34:12 -0500

Overall I like the idea. But we have to separate format from content.
Sarah's idea for JWL sounds like a proposal for syslog in the JSON era, and
that is a very good thing.

If we think about JWL like syslog, then it fixes just enough format for
multiple producers and consumers to use and also allows multiple
organizations to design specific content types, like Justin points to,
independently. This would allow SCIM WG, OpenID RISC, etc to do their
things.

Just my $0.02

On Wed, Feb 3, 2016 at 5:52 PM, Justin Richer <[email-masked]> wrote:

> I think this is a really great idea. It’s the kind of abstraction that the
> “ID Events” conversation was pointing towards initially, by my view. I
> actually see the JWL as the superset, since the events aren’t always “ID
> related”.
>
>  “I’m an AS and a third-party account was used to access a user’s
> resources by their policy (think UMA), I need to record something and tell
> the user at their designated endpoint.”
>
>
> What would each of these strawmen look like as JSON objects inside of a
> JWL? Can we start to extract common claims? I don’t think that JWT is
> necessarily going to be a good base, but it might be reasonable to start
> there. What’s the issuer, subject, and audience of each statement? How do
> we record the kind of action? Do we have an ontology or registry?
>
> Lots of very important questions will start to fall out, and hopefully
> their answers too, once we start putting JSON to the page.
>
>  — Justin
>
>
> I think it is terrific thinking and very insightful.  We are very
> interested in this for consent events and the delegation of consent for a
> wide array of access control notices and transactions which relate to
> consent records.  It appears work like this  would extend the core of the
> consent work we are doing and I think its very well timed, a super
> efficient and technically great approach to the set of problems in this
> space.
>
> The JWT logging is brilliant :-)     Personally, I think the Consent and
> Information Sharing  WG would be very happy to see your work move in this
> direction and I would hope that we could compliment it.
>
> Mark Lizar
> Executive Director
> Open Consent Group
>
> *Engineering - Architecture & Global Deployment *– Monforte de Lemos,
> s/n, 28029
> Maps:

-- 
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer <https://twitter.com/iglazer>