[Openid-specs-risc] Account State Events Format

Marius Scurtescu mscurtescu at google.com
Thu May 18 01:52:56 UTC 2017


Yes, this could be a drawback, but I really don't think the extra level is
a significant issue for several reasons:
- almost for sure the hijacking and bot events in particular will need
other nested attributes like timestamps (time of hijacking and time of
disabling the account)
- only the sofisticated receivers will have to look at the nested
attributes, very unlikely they will have a problem with that
- most likely libraries will be used, exposing the attributes should be no
issue
- the whole SET is already nested several levels, people know how to parse
JSON, even if a receiver is writing its own code to parse, how likely it is
they will have issues?

On the other hand, I am trying to prevent a naive receiver that only cares
about session handling to naively look only for "
http://schemas.openid.net/risc/event-type/account_disabled" and miss the
other events because they have a suffix, or because they look funny.

Marius

On Wed, May 17, 2017 at 5:32 PM, Hardt, Dick <dick at amazon.com> wrote:

> I’m not super keen on having second layer of information about an event as
> it adds complexity, and this seems like the only place we want to do it. (I
> do think you proposed one other place)
>
>
>
> An alternative way of providing the additional information is to append
> chars to the string. For example
>
>
>
> http://schemas.openid.net/risc/event-type/account_disabled
>
> *http://schemas.openid.net/risc/event-type/account_disabled
> <http://schemas.openid.net/risc/event-type/account_disabled>_bot*
>
> *http://schemas.openid.net/risc/event-type/account_disabled
> <http://schemas.openid.net/risc/event-type/account_disabled>_hijacking*
>
> *http://schemas.openid.net/risc/event-type/account_enabled
> <http://schemas.openid.net/risc/event-type/account_enabled>*
>
>
>
> *This lets developers that only care about
> http://schemas.openid.net/risc/event-type/account_disabled
> <http://schemas.openid.net/risc/event-type/account_disabled> to look at
> events that start with that, rather than it being a JSON object.*
>
>
>
> */Dick*
>
>
>
> On 5/17/17, 5:23 PM, someone claiming to be "Openid-specs-risc on behalf
> of Marius Scurtescu" <openid-specs-risc-bounces at lists.openid.net on
> behalf of mscurtescu at google.com> wrote:
>
>
>
> At the face-to-face a couple of weeks ago and also on Monday during our
> call we talked about RISC events that reflect an account state change
> between disabled and enabled. For example, account hijacked / recovered,
> account deleted / undeleted, etc.
>
>
>
> On one hand there are privacy concerns, and for example if a user violated
> ToS with a provider then that fact should not be disclosed (I think we have
> agreement here).
>
>
>
> On the other had at least with some of the event we do want to be very
> specific so abuse systems get a quality signal.
>
>
>
> So far the agreement was that hijacking and accounts created by bots need
> a distinct signal, everything else can use a generic one.
>
>
>
> I am proposing the following format:
>
>
>
> 1. All of these events will use these two event type URIs:
>
> http://schemas.openid.net/risc/event-type/account_disabled
>
> http://schemas.openid.net/risc/event-type/account_enabled
>
>
>
> 2. For hijacking and bot created the transmitter should add a nested
> attribute called "reason" with values like "hijacking" and "bot"
>
>
>
> An example:
>
> {
>
>   "iss": "https://server.example.com",
>
>   "sub": "248289761001",
>
>   "aud": "s6BhdRkqt3",
>
>   "iat": 1471566154,
>
>   "jti": "bWJq",
>
>   "events": {
>
>     "http://schemas.openid.net/risc/event-type/account_disabled":
>
>     {
>
>       "reason": "hijacking",
>
>     }
>
>   }
>
> }
>
>
>
> We can define more values for "reason" and transmitter could chose to
> provide them. The more distinct events are provided the easier it is to
> identify the ToS cases through elimination, so there should be a good
> reason to be specific (if ToS privacy is a concern).
>
>
>
> Sounds good? Thoughts?
>
>
>
> There are other ways to capture these requirements (distinct URIs for
> hijacking and bot or multiple URIs), but this is the most concise and the
> safest for developers who are only interested in account state (so they
> don't have to deal with event URIs they don't fully understand or care
> about).
>
>
>
> Marius
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170517/bb8f3595/attachment.html>


More information about the Openid-specs-risc mailing list