I have lots of objections, but we will start with these 2 1. Name, I suggest a name of "token delegation" 2. Issue here is that OIDF started down a dynamic registration path, and then IETF wanted to do this and in a somewhat different way , so why start this nightmare, cull out the basic exchanges/structures/schema/etc. needed for delegation make that an IETF draft and then anything that is OIDF specific become work in OIDF.
From: Paul Madsen [mailto:[email protected]] Sent: Wednesday, July 3, 2013 3:10 PM To: Anthony Nadalin Cc: Mike Jones; John Bradley; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [OIDFSC] Native application SSO Working Group you are making two objections - let's keep them separate 1) naming - UMA (as an example) does set a precedent of describing a profile in terms of something more abstract than its mechanics. Ultimately, profiles are *meant* to do one thing - and this one is meant to 'do SSO' 2) forum - I fail to see how doing the work of creating a profile of OIDC could be any easier or more straightforward in the IETF than the body that defined the spec itself?? paul On 7/3/13 5:59 PM, Anthony Nadalin wrote: The user experience may be SSO but that is only 1 type of experience, this is a byproduct of the token delegation. I don't want the situation we are in with dynamic registration we are now, having to keep the OIDF work in sync with the IETF work, its suck. I think this could be easily profiled in IETF to be generic and then anything specific can be done in OIDF From: Paul Madsen [mailto:[email protected]] Sent: Wednesday, July 3, 2013 2:47 PM To: Anthony Nadalin Cc: Mike Jones; John Bradley; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [OIDFSC] Native application SSO Working Group it enables a 'login once, enjoy seamless access' across multiple native apps - how is that not SSO? While the mechanism may be token delegation, the user experience is SSO The proposal is to profile OIDC - it's not a distinct protocol - that's why we are bringing it to OIDF paul On 7/3/13 5:42 PM, Anthony Nadalin wrote: This is a real crappy name, as its not SSO, it's a "token delegation agent" (so proposal is to handle both authentication and authorization). Question is does it belong here or at IETF, if the dynamic registration fits in IETF why wouldn't this ? -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Mike Jones Sent: Wednesday, July 3, 2013 2:26 PM To: John Bradley; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Paul Madsen; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: [OIDFSC] Native application SSO Working Group This proposed charter did not incorporate any of the proposed improvements and clarifications that I circulated to the authors - not even the spelling corrections or the (I believe necessary) statement that "This specification will not make breaking changes to OpenID Connect 1.0". My proposed version is attached. I would appreciate it you would resubmit the charter with these corrections incorporated. After that, I will support the formation of the working group. Thank you, -- Mike -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of John Bradley Sent: Sunday, June 30, 2013 5:35 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Paul Madsen; Chuck Mortimore; [email protected]<mailto:[email protected]>; Nat Sakimura; matake@gmail; [email protected]<mailto:[email protected]> Subject: [OIDFSC] Native application SSO Working Group The enclosed Work Group Charter is being sent to the Specs Council for review in anticipation of chartering the Group. It is best have this activity under the foundation IPR as soon as possible. Regards John B.
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
