[OpenID board] [OIDFSC] Native application SSO Working Group
ve7jtb at ve7jtb.com
Thu Jul 4 00:41:04 UTC 2013
We floated the idea of starting this as a IETF ID, but it was felt that getting it under the OIDF IPR policy as soon as possible was preferable if any of it was to become a OIDF spec.
I would not characterize the Dynamic registration work as a disaster of any sort. It is true that once in the IETF these things are harder to keep focuses, however that argues for developing the profile inside the OIDF.
Given that we have already included some things in connect like "azp" to enable intermediate agent to get id_tokens to be consumed by 3rd parties we also considered doing it in the connect WG.
I personally thought a separate WG was preferable to avoid people who have IPR commitments to Connect from being forced to make them for this without taking an affirmative action to join the WG.
As we dig into this the work may need to be separated into several specifications as delegation of a token to a 3rd party, basing authorization of a 3rd parties resource server on an external assertion, bootstrapping web applications from a native app, and proxying OAuth requests. That will be the decision of the WG once it is chartered.
I appreciate your intrest in making sure that we correctly set the scope of the WG.
On 2013-07-03, at 5:59 PM, Anthony Nadalin <tonynad at microsoft.com> 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:pmadsen at pingidentity.com]
> Sent: Wednesday, July 3, 2013 2:47 PM
> To: Anthony Nadalin
> Cc: Mike Jones; John Bradley; specs-council at openid.net; ashishjain at vmware.com; openid-board at lists.openid.net; openid-specs at lists.openid.net
> 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
> 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: openid-specs-bounces at lists.openid.net [mailto:openid-specs-bounces at lists.openid.net] On Behalf Of Mike Jones
> Sent: Wednesday, July 3, 2013 2:26 PM
> To: John Bradley; specs-council at openid.net
> Cc: ashishjain at vmware.com; Paul Madsen; openid-board at lists.openid.net; openid-specs at lists.openid.net
> 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: openid-specs-council-bounces at lists.openid.net [mailto:openid-specs-council-bounces at lists.openid.net] On Behalf Of John Bradley
> Sent: Sunday, June 30, 2013 5:35 PM
> To: specs-council at openid.net
> Cc: ashishjain at vmware.com; Paul Madsen; Chuck Mortimore; openid-specs at lists.openid.net; Nat Sakimura; matake at gmail; openid-board at lists.openid.net
> 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.
> John B.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the board