[Openid-specs-risc] RISC WG Meeting 2/12

Richard Backman, Annabelle richanna at amazon.com
Mon Feb 12 22:00:09 UTC 2018


Mike described his expectations for SET, then said that “This is exactly parallel to the interoperability expectations for JWTs.” And then described JWT interop. At the Cisco meeting, he agreed with my characterization of his position as no expectation of interop across unrelated profiles.

I don’t see much value in pursuing generalized solutions for delivery or stream management when nothing else is generalizable.

--
Annabelle Richard Backman
Amazon – Identity Services

From: Phil Hunt <phil.hunt at oracle.com>
Date: Monday, February 12, 2018 at 1:35 PM
To: Phil Hunt <phil.hunt at oracle.com>
Cc: "Richard Backman, Annabelle" <richanna at amazon.com>, Dick Hardt via Openid-specs-risc <openid-specs-risc at lists.openid.net>
Subject: Re: [Openid-specs-risc] RISC WG Meeting 2/12

Sorry I meant to say Yaron’s question - it was not originally Annabelle’s

Mike responded on what was the basis for interop on JWT. I agreed with his interpretation.

I suggest re-posting this as a question on interop for delivery.


Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<http://www.independentid.com>
phil.hunt at oracle.com<mailto:phil.hunt at oracle.com>


On Feb 12, 2018, at 12:16 PM, Phil Hunt via Openid-specs-risc <openid-specs-risc at lists.openid.net<mailto:openid-specs-risc at lists.openid.net>> wrote:

When I saw your question I assumed it was about SETs interop as we were discussing finalizing the SET draft.

Now your question makes more sense.

I suggest re-posing the question in the frame of management and delivery to get people to comment.

Phil

On Feb 12, 2018, at 12:07 PM, Richard Backman, Annabelle <richanna at amazon.com<mailto:richanna at amazon.com>> wrote:
I said that the question of expected interoperability between SETs was brought up on the id-events mailing list. See below:

In this thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00963.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MQS6mJLjyHFXUbXGVdu1VOCM8RninJO_NiHdrVWdD1M&s=who-RXL5EW5OBVeLvgAOC5vhKmbpUkkPNAT6K0EmveM&e=>, Yaron stated that there was no rough consensus on the single-event syntax issue; to drive the conversation forward, he raised three topics:

- What is the value of a SET, in addition to its being "a kind of JWT". Specifically, let's assume a software architecture that consists of three layers: SET profile-specific library, generic SET processor, generic JWT library. What would be the functionality (or the added value) of the middle layer?


- What are the existing implementations that prevent change to the current spec, even changes as trivial as renaming "events" to "event"? Are there any production or near-production implementations in addition to the OIDC Back Channel Logout (which is arguably a trivial use of SET)? From an IETF process point of view, I'd like to point out that any I-D is completely open to changes until actual publication as an RFC, and certainly until it is delivered to the IESG.

- What are our interoperability expectations? One of the participants mentioned that his company will only send single events and will "prefer" to receive single events. Can such an implementation be interoperable with all RFC compliant implementations? If we leave too much of the SET semantics for profiles to define, are we sacrificing interoperability?

Mike replied with his view on these topics, notably that the interoperability expectations for SET are the same as those for JWT, and “there is no expectation” of interoperability between unrelated SETs. I replied with my understanding, that some degree of interoperability is expected – specifically, that if SET is going to permit embedding events from different profiles within the same token, then any two arbitrary event types ought to be combinable. No one else commented at the time, and the thread became a discussion of Mike’s proposed changes to clarify the non-interoperability. Youcommented<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00971.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MQS6mJLjyHFXUbXGVdu1VOCM8RninJO_NiHdrVWdD1M&s=m8d1gOZGb_Xoq5sgSCtkTgI-abOluKB0wRofCf5Tnkg&e=> that you were “ok with Mike’s new changes,” and said nothing about the questions raised by Yaron. Later in the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00981.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MQS6mJLjyHFXUbXGVdu1VOCM8RninJO_NiHdrVWdD1M&s=HrqrkwSrsdcROkWIZAHkxV07ZkZUoEzCmlWiHRJQL7k&e=>, I raised the expected interoperability question again and asked for a consensus call on that question before accepting Mike’s revisions as -04 of the SET draft. Justin +1’d my concern and Mike argued against it, but no one else commented.

In this thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg01017.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MQS6mJLjyHFXUbXGVdu1VOCM8RninJO_NiHdrVWdD1M&s=siVxM_yrq2WkDXuLOEbMMLiT8WOaJG62SlPoUMv2E8k&e=>, I acknowledged that RISC the -05 draft can work for RISC, but noted that the resulting RISC spec will likely be incompatible with all other SET profiles. Marius agreed with both of those statements, and Luke and Adam +1’d that -05 will work for RISC.

--
Annabelle Richard Backman
Amazon – Identity Services

From: Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net<mailto:openid-specs-risc-bounces at lists.openid.net>> on behalf of Phil Hunt via Openid-specs-risc <openid-specs-risc at lists.openid.net<mailto:openid-specs-risc at lists.openid.net>>
Reply-To: Phil Hunt <phil.hunt at oracle.com<mailto:phil.hunt at oracle.com>>
Date: Monday, February 12, 2018 at 11:18 AM
To: Adam Dawes <adawes at google.com<mailto:adawes at google.com>>
Cc: Dick Hardt via Openid-specs-risc <openid-specs-risc at lists.openid.net<mailto:openid-specs-risc at lists.openid.net>>
Subject: Re: [Openid-specs-risc] RISC WG Meeting 2/12

Thanks everyone.

Annabelle, can you provide the link where the issue was brought up in SECEVENTs? I’m not sure what exactly the question posed was to search for it.

Certainly the SECEVENTs charter itself says the group is producing a control plane (aka management API) that likely would cover most of the items in Marius’s draft. There has been no formal call to change the charter in this respect.



Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MQS6mJLjyHFXUbXGVdu1VOCM8RninJO_NiHdrVWdD1M&s=mRSNAWH-uHMazSN82i5HVTkRF7itXIZgMUanueRaMZk&e=>
phil.hunt at oracle.com<mailto:phil.hunt at oracle.com>



On Feb 12, 2018, at 10:39 AM, Adam Dawes via Openid-specs-risc <openid-specs-risc at lists.openid.net<mailto:openid-specs-risc at lists.openid.net>> wrote:

Attendees: Phil Hunt, Roshni Chandrasekhar, Annabelle Backman, Luke Camery, Adam Dawes, Henrik Biering

Legal Summary

  *   Over 20 people and 10 companies represented
  *   Offered presentation to bring everyone up to speed on efforts
  *   Working on generic bi-lateral agreement which will then be made public for re-use by the community. Google collaborating directly with Amazon right now on draft to bring to the WG to be adopted. Any two parties are free to modify the agreement as they would like. Google's plan is to not negotiate further after this initial draft is finalized.
Spec Feedback
Phil had some concerns about the management API.
AI: Phil to send specific points he wants to bring up to the list.

"Verified" attribute for add/remove subject
Verified attribute outside the subject identifier was previous agreement. This might not always work. If we have ID Token subject type along with others in the subject, it is not clear which claim verified pertains to.

Let's have a more rigorous definition of what verified means. Can't come up with a definition that doesn't meet with how most providers have implemented- many may not exactly know the verification method or time.

Proposed definition: Service provider has verified an account if they have sent a message (email, SMS) to the user's address and the user has acknowledged the receipt from the service provider by replying back to the service provider by clicking a link or entering a code at the service provider.

Questions: Does a marketing email with a click on a link work? Is a receipt where the recipient can dispute the transaction but doesn't do so an indication that the account is verified?

One or many streams
Discussion about what should live in RISC and what should live in SecEvents.
Phil believes some items in Marius' drafts should live in SecEvents.
Commentary that this was brought up in SecEvents already by Annabelle and the group did not take it up. RISC trying to define something to meet our base cases. No objection if that later is taken to SecEvents but want to unblock now.

Future Meetings
Group agreed that we would have an additional meeting on Wednesday afternoon this week. Luke will schedule.
At that meeting we will find a time for a meeting next week given Monday is a US holiday.
After next week, we will move to a weekly meeting cadence on Mondays.


On Sun, Feb 11, 2018 at 8:10 PM, Luke Camery <lcamery at google.com<mailto:lcamery at google.com>> wrote:
Dear All,

The RISC working group will meet tomorrow at 09:30 PST.

Agenda
1. Recap of legal summit
2. Discussion of Marius' RISC Profile draft:
- "verified" attribute for add/remove subject
- discovery URL, path before or after .well-known
- one or many streams

The call in details are below.

Thanks,
Luke

https://global.gotomeeting.com/join/576653581<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fq-3Dhttps-253A-252F-252Fglobal.gotomeeting.com-252Fjoin-252F576653581-26sa-3DD-26ust-3D1518415757211000-26usg-3DAFQjCNH7ZIi2zl7C0-2D32TKJtZ1qyaek8zQ&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=mlGR2GZ5OQO3mqBq8fZEtiQ3GFTWUgBt-jwBtVht8Hc&s=bDynMzt5wlRTJERUczT53c4STA5EmvIBx26WaeSmyAc&e=> You can also dial in using your phone. United States +1 (786) 358-5410<tel:(786)%20358-5410> Access Code: 576-653-581 More phone numbers Australia (Long distance): +61 2 9087 3604<tel:+61%202%209087%203604> Austria (Long distance): +43 7 2088 1400 Belgium (Long distance): +32 (0) 92 98 0592 Canada (Long distance): +1 (647) 497-9350 Denmark (Long distance): +45 69 91 88 62 Finland (Long distance): +358 (0) 942 41 5778 France (Long distance): +33 (0) 182 880 456 Germany (Long distance): +49 (0) 692 5736 7211 Ireland (Long distance): +353 (0) 14 845 976 Italy (Long distance): +39 0 247 92 12 39 Netherlands (Long distance): +31 (0) 208 080 379 New Zealand (Long distance): +64 4 974 7215 Norway (Long distance): +47 21 03 58 96 Spain (Long distance): +34 911 82 9782 Sweden (Long distance): +46 (0) 313 613 558 Switzerland (Long distance): +41 (0) 225 3314 51 United Kingdom (Long distance): +44 (0) 20 3535 0621


--
[http://i.imgur.com/Ya4Rhss.gif]

  •  Luke Camery
  •  Associate Product Manager
  •  Federated Identity




--
Adam Dawes | Sr. Product Manager | adawes at google.com<mailto:adawes at google.com> | +1 650-214-2410

_______________________________________________
Openid-specs-risc mailing list
Openid-specs-risc at lists.openid.net<mailto:Openid-specs-risc at lists.openid.net>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Drisc&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=mlGR2GZ5OQO3mqBq8fZEtiQ3GFTWUgBt-jwBtVht8Hc&s=tBc8537ZofF8FmxVFTpZzeD7mfrjgbFo1OBQDEpVC88&e=

_______________________________________________
Openid-specs-risc mailing list
Openid-specs-risc at lists.openid.net<mailto:Openid-specs-risc at lists.openid.net>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Drisc&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=tyzXp16L0M1LfzuA8S9y53iX2wWWruLVJzfQiLV6Xtk&s=JUZMAiMTUvkqN47fRnxCfhduna6D-OqSiHWEhftXWlE&e=

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20180212/c7244211/attachment-0001.html>


More information about the Openid-specs-risc mailing list