[Openid-specs-risc] RISC Working Group Meeting 3/26

Adam Dawes adawes at google.com
Mon Mar 26 22:55:44 UTC 2018


Attendees
Adam Dawes, Marius Scurtescu, Roshni Chandrashekhar, Shreyas Saitawdekar,
Annabelle Backman

F2F @ IIW (April 5)

   - We'll huddle at IIW to work on agenda
   - Marius will reserve room at Google for event

-- Updates to core RISC signals draft ---
Marius sent updated specs
<https://bitbucket.org/openid/risc/src/faa03fdd6adc56365a8bda3d67aab97ad08e0630/risc-event-types.txt?at=master&fileviewer=file-view-default>
over the weekend. Reviewed items from change log
<https://bitbucket.org/openid/risc/overview>.

   - Renamed account_deleted to account_purged
   - Dropped cause-time from the event because there is now toe at the SET
   level
   - identifier_changed has attribute new_value which is optional instead
   of required. Also expanded description to not confuse with recovery
   information changes. Should only sent by authoritative provider.

One question: Two opt-out related events: opt_in, opt_out_cancelled. They
both mean user is going to opt-in state but coming from two different
opt-out states. Do we need two?

*We've now closed on this round of feedback around the signals and Google
will implement to these signals and definitions. We can revisit based on
operational experiences but the bar for change will be higher. *

-- OAuth Events --
Marius sent spec
<https://bitbucket.org/openid/risc/src/faa03fdd6adc56365a8bda3d67aab97ad08e0630/oauth-event-types.txt?at=master&fileviewer=file-view-default>
to the list.
Five events defined so far. Strong assumption at the beginning: aud claim
in the SET is the clientID of the OAuth client. No comment on that being a
problem
Signals

token_revoked

   - token_type (three values: refresh_token, access_token,
   authorization_code)
   - token_identifier_type (three values: token_string,
   token_string_prefix, token_string_hash)
   issuer needs to make sure that the string prefix is unique. May require
   user to be identified
   - token: string that identifies the token
   - token_string_hash_algorithm (optional if hash algorithm is used as
   token_type. Still fleshing this out)

Question: Should we pull out token_string_hash until someone wants to do
that?
*AI [Marius]*: provide advice around when the token could have a collision
and when to include a user identifier and when not to.

tokens_revoked
No identifying of individual tokens, instead all tokens for that user have
been dropped for the client identified by the audience

client_disabled
No attributes or subject. Client is defined by audience claim. Any request
for that client will generate an error. No 'reason' attribute at this
point. Refresh and access tokens will stop working.

client_enabled
Client has started working again. Lots of reasons why clients disabled and
lots of those reasons could be errors.

client_credential_changed
One of the credentials issued for that client have changed. Could be client
secret or private key rotated. Probably will mean an outage unless
deliberately planned by the developer.

John Bradley agreed to review the spec and provide feedback.

Annabelle comments:

   - token_revoked -> token_type parameter should support arbitrary URIs
   because that's how you define extension types for OAuth2
   - client events: can't assume that audience always pertains to the
   client_id. For Amazon, they have applications which may relate to multiple
   client_ids. May want to set for application. May also break down in dynamic
   client scenarios. OP may not have full list of clients.

Marius thinking about adding subject claim which would relate to the
clientID. May not work when need to identify user.

Should this spec happen in OAuth working group. Marius: let's start here
and we can move to IETF if people feel that is important.

-- IETF recap --

   - We will split delivery draft into PUSH and PULL drafts. Whole question
   about MTI goes away.
   Majority of people saw them targeting different use cases. Questions
   about how this would work out through IETF. New AD said that WG would
   probably be called on it but would be okay with justification.
   - Annabelle will write draft and submit wg draft for subject identifier
   types.
   - Expired claim. No consensus on what to do. How does one understand
   semantics of expired claim.


On Sun, Mar 25, 2018 at 11:10 PM, Adam Dawes <adawes at google.com> wrote:

> Just a reminder about the RISC call Monday at 3pm PDT.
>
> On Thu, Mar 22, 2018 at 11:47 PM, Luke Camery via Openid-specs-risc <
> openid-specs-risc at lists.openid.net> wrote:
>
>> Hello,
>>
>> The RISC WG will meet on 3/26 at 3pm PST. We will continue our high
>> priority discussion on the RISC signals then move onto the primary RISC
>> spec.
>>
>> Please check the issue tracker and leave any comments that you have
>> before then!
>>
>> *Agenda*
>> 1. Updates to RISC signals and discussion of updated draft
>> 2. Discussion of OAuth signals draft
>> 3. Updates to main spec
>>
>> *Call Details*
>> 1. Please join my meeting. https://global.gotomeeting.com/join/576653581
>> 2. Or call in at: +1 (312) 757-3119 <(312)%20757-3119>
>>
>> --
>>
>> *  •  **Luke Camery*
>> *  •  *Associate Product Manager
>> *  •  *Federated Identity
>>
>>
>> _______________________________________________
>> Openid-specs-risc mailing list
>> Openid-specs-risc at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-risc
>>
>>
>
>
> --
> Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
> <(650)%20214-2410>
>
>


-- 
Adam Dawes | Sr. Product Manager | adawes at google.com | +1 650-214-2410
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20180326/32fb052f/attachment.html>


More information about the Openid-specs-risc mailing list