[Openid-specs-risc] RISC WG 4/5 - Meeting Notes

[Luke Camery]

*SummaryThe working group sorted out most the the existing blockers with
high enough confidence to send the specifications through to last call. WG
Chair, Adam Dawes, will initiate this process with the assistance of OIDF
Secretary, Mike Jones.Action Items 1. Luke Camery: find out legal
requirements for service provider to guide spec drafting2. Janrain: loop in
product people with lcamery at google.com <lcamery at google.com> and
adawes at google.com <adawes at google.com>3. Adam Dawes, Marius Scurtescu,
Annabelle Richard-Backman: send specs through implementers draft (last
call) process1. Work with Mike Jones on this4. Marius Scurtescu: deal with
open questions about audience in revisions5. Marius Scurtescu: use BCP190
for RISC6. Marius Scurtescu: suggest “best practice” canonicalizationFull
Notes 1. IntroductionsAdam Dawes(Google), Marius Scurtescu (Google), Roshni
Chandrashekhar (Google), Dick Hardt (Amazon), Tony Nadalin (Microsoft),
John Trammel (Adobe), John Bradley (Yubico), Micah Carrick (Janrain), Paolo
Tanimoto (Janrain), Cristian Opincaru (Adobe), Anabelle Richard-Backman
(Amazon), Mike Jones (Microsoft) 1. Agenda setting2. Legal Update
(adawes at google.com <adawes at google.com>) = Slow moving but we're close =
Google and Amazon are driving and will donate back = Note that Google is
ready to play with another agreement if interested = Note that Janrain
style providers will need special legal work to make sure they can manage
for others- Google Interop (Marius Scurtescu) = Tell Google your client-id
and we can whitelist you = Mailing list with test users that we can add
test users to = Testing requires no legal, real users requires legal = We
have agreement you can sign now if you want! = Google is supporting push
(HTTP POST) for delivery = Marius Scurtescu and Roshni will help configure
your client ID, help with test accounts, debugging, etc = Amazon:Google
interop (ASAP) 1. Obtain an access token 2. Amazon call add subject 3.
Amazon have simple endpoint to receive (blind reply 202) 3.5 Google have
storage 4. Google open pipeline and send events = Adobe is interested in
starting work with staging clients - Focusing on this in July - Maybe
starting endpoint sooner since low work with explicit4. How to do
delegation for IdaaS? = Adam Dawes: Google considering letting client
secret work as AT so that you can configure on behalf of customers - Marius
Scurtescu walks through ToS issues and AT issues - Discussion of data
ownership sensitivities - Special legal agreement needed with Google to
accept on behalf of customers - Option: Customers will delegate their RISC
streams to provider's client-id - Marius Scurtescu: Will we ever support
client credential grant? idk - NOT GOOGLE SPECIFIC. Google working on
generic plan that others can copy. - Standardization of token delegation
may occur later, not scheduled work - Marius Scurtescu walks through
delegation model from 3P to service provider - Adam Dawes: It's important
that janrain is able to take responsibility for acme, less important that
janrain is acting as acme - Janrain agreement and then using client secret
is superior to full delegation due to complexity of agreement vs complexity
of management - Dick Hardt: managing each one one by one is easier than
managing them all together - Product/Legal decisions to be made around
whose liability is where and what the requirement is - AI:
lcamery at google.com <lcamery at google.com> will follow up with legal about how
this should be designed and then Marius Scurtescu can design it - Janrain:
we'd like to do it, but let's see what product says - AI: janrain will loop
in product people with lcamery at google.com <lcamery at google.com> and
adawes at google.com <adawes at google.com> - Open question: can we do implicit
case here as well? - IDaaS is a thing, if we get the few IDaaS players
onboard then we can unlock so many more users just by working with a few
players. Huge value for small targeted legal effort with a few large
players. - Mike Jones loves that reasoning and is willing to work with MSFT
lawyers on unlocking this for their IDaaS customers though Azure will be
impossible5. Timeline for Overall Launch = Discussion on what we'd like to
announce - Adam Dawes: we're going to help a lot of users keep their
accounts more secure - Adam Dawes: we could just launch our tools and say
others should adopt them - Adam Dawes: we'd PREFER to say everyone is
already working on our tools together - Amazon views legal agreement as
accelerate - Amazon would consider launching before full interop done -
Mike walked through how we get through OIDF process - AI: Adam Dawes will
send events through to implementers draft - Dick Hardt: Let's adjust to
secevents and then move everything forward - Dick Hardt: Implementer draft
may change, but given the data we have now this is how we're moving forward
- DECISION: Editors will identify specific drafts and work with Mike to put
them onto oidf.net <http://oidf.net> with WG last call and move them
forward6. Mike Jones and Tony setting up MSFT meeting the 20th in
Bellevue/Redmond7. Audience = Marius Scurtescu: needed to be less tied to
oauth2 - using client-id but everyone has a concept of "projects" - Not
meaningful in oauth 2 context - Grants are tied to client-id so it makes
sense = Dick Hardt: maybe put it in the config rather than client-id - More
configurable and bespoke = Open Questions - Singular or plural? - What
should the aud value be? - Client-id or something else? AT related? = AI:
Marius Scurtescu to deal with these in revisions- Discovery Document Path =
Mike Jones demos issue on conflict between openid and oauth config rule
with .well-known = Microsoft uses openid config at the end of path = MSFT
doesn't support an RFC backed standard = Mike Jones: Suggest using new
.well-known and follow standard for RISC in order to avoid blocking it from
ever touching IETF = Mike Jones: BCP190 "URI design and ownership" and will
send the file to Marius Scurtescu AI: Marius Scurtescu: use BCP190 for RISC
= Adam Dawes: We should probably do an IANA registration for the
risc-configuration path component.8. Canonicalization = Dick Hardt:
Lightweight proposal, should just be suggest to do something but not much =
Marius Scurtescu: Anything is too much and should just tell someone else to
do this work = Decision: Just write "best practice is to canonicalize" =
AI: Marius Scurtescu: just suggest best practice*


-- 

*  •  **Luke Camery*
*  •  *Associate Product Manager
*  •  *Federated Identity
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20180406/406ea1cc/attachment-0001.html>