[Openid-specs-risc] Account State Events Format

Marius Scurtescu mscurtescu at google.com
Thu May 18 18:21:18 UTC 2017


On Thu, May 18, 2017 at 6:52 AM, Hardt, Dick <dick at amazon.com> wrote:

> Marius:
>
> "Libraries" will solve it was the argument  dismissing the complexity of
> OAuth 1.O, but people got it wrong a lot still.
>

Right, but again, we are talking trivial complexity here (4 level nested
JSON vs 3 level nested) and not Diffie–Hellman.


>
> I'm unclear how the JSON would look in other events. Would you show the
> alternative?
>

Good point.

Account enabled is always the same:
{
  "iss": "https://server.example.com",
  "sub": "248289761001",
  "aud": "s6BhdRkqt3",
  "iat": 1471566154,
  "jti": "bWJq",
  "events": {
    "http://schemas.openid.net/risc/event-type/account_enabled": {}
  }
}

Account disabled for ToS, deleted by user or disabled by admin:
{
  "iss": "https://server.example.com",
  "sub": "248289761001",
  "aud": "s6BhdRkqt3",
  "iat": 1471566154,
  "jti": "bWJq",
  "events": {
    "http://schemas.openid.net/risc/event-type/account_disabled": {}
  }
}



>
> Another approach would be to have two events in the "events" property, a
> general event http://schemas.openid.net/risc/event-type/account_disabled
>
> And a more specific event
>
> http://schemas.openid.net/risc/event-type/account_disabled_bot
>
>
Yes, here is an example for this case:
{
  "iss": "https://server.example.com",
  "sub": "248289761001",
  "aud": "s6BhdRkqt3",
  "iat": 1471566154,
  "jti": "bWJq",
  "events": {
    "http://schemas.openid.net/risc/event-type/account_disabled": {},
    "http://schemas.openid.net/risc/event-type/account_disabled_bot": {}
  }
}


As Phil mentioned, we may end up pushing both iss and sub down to the event
level (either for all events to disambiguate from Id Tokens, or only in
some cases), in which case the above SET becomes:
{
  "iss": "https://transmitter.server.example.com",
  "aud": "s6BhdRkqt3",
  "iat": 1471566154,
  "jti": "bWJq",
  "events": {
    "http://schemas.openid.net/risc/event-type/account_disabled":
    {
      "iss": "https://server.example.com",
      "sub": "248289761001"
    },
    "http://schemas.openid.net/risc/event-type/account_disabled_bot":
    {
      "iss": "https://server.example.com",
      "sub": "248289761001"
    },
  }
}

As opposed to:
{
  "iss": "https://transmitter.server.example.com",
  "aud": "s6BhdRkqt3",
  "iat": 1471566154,
  "jti": "bWJq",
  "events": {
    "http://schemas.openid.net/risc/event-type/account_disabled":
    {
      "iss": "https://server.example.com",
      "sub": "248289761001",
      "reason": "bot"
    },
  }
}

If possible I think it is better to reduce the number of events in one SET.

Even with generic disable/enable events, we may end up with multiple events
in some cases anyhow, for example:
{
  "iss": "https://transmitter.server.example.com",
  "aud": "s6BhdRkqt3",
  "iat": 1471566154,
  "jti": "bWJq",
  "events": {
    "http://schemas.openid.net/risc/event-type/sessions_revoked":
    {
      "iss": "https://server.example.com",
      "sub": "248289761001"
    },
    "http://schemas.openid.net/risc/event-type/account_disabled":
    {
      "iss": "https://server.example.com",
      "sub": "248289761001",
      "reason": "bot"
    },
  }
}


> I think it is useful for the WG to see the various approaches and everyone
> can then have a better understanding of the pros and cons.
>

Agreed.



>
> -- Dick
>
> On May 17, 2017, at 6:54 PM, Marius Scurtescu <mscurtescu at google.com>
> wrote:
>
> 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/20170518/4efb9c53/attachment-0001.html>


More information about the Openid-specs-risc mailing list