[OpenID board] [OIDFSC] Native application SSO Working Group

Mike Jones Michael.Jones at microsoft.com
Thu Jul 4 01:03:51 UTC 2013


I agree with John's point that we want to get this work under OIDF IPR protections ASAP.  That's why I've been encouraging Paul to submit the charter and get the working group approved so we can start collecting IPR agreements.

I believe that whether the working group eventually decides to factor the work to also include working on specifications in the IETF or other organizations is a separable issue.  It's clear that there's an OIDF-specific portion because part of the work is a profile of OpenID Connect, so at the very least, we need to establish IPR protections using the working group process for that portion of the work.

                                                                -- Mike

From: John Bradley [mailto:ve7jtb at ve7jtb.com]
Sent: Wednesday, July 03, 2013 5:41 PM
To: Anthony Nadalin
Cc: Paul Madsen; Mike Jones; 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

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.

John B.

On 2013-07-03, at 5:59 PM, Anthony Nadalin <tonynad at microsoft.com<mailto: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<http://pingidentity.com>]
Sent: Wednesday, July 3, 2013 2:47 PM
To: Anthony Nadalin
Cc: Mike Jones; John Bradley; specs-council at openid.net<mailto:specs-council at openid.net>; ashishjain at vmware.com<mailto:ashishjain at vmware.com>; openid-board at lists.openid.net<mailto:openid-board at lists.openid.net>; openid-specs at lists.openid.net<mailto: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

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: openid-specs-bounces at lists.openid.net<mailto: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<mailto:specs-council at openid.net>

Cc: ashishjain at vmware.com<mailto:ashishjain at vmware.com>; Paul Madsen; openid-board at lists.openid.net<mailto:openid-board at lists.openid.net>; openid-specs at lists.openid.net<mailto: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> [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<mailto:specs-council at openid.net>

Cc: ashishjain at vmware.com<mailto:ashishjain at vmware.com>; Paul Madsen; Chuck Mortimore; openid-specs at lists.openid.net<mailto:openid-specs at lists.openid.net>; Nat Sakimura; matake at gmail; openid-board at lists.openid.net<mailto: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.



Regards

John B.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-board/attachments/20130704/98bc5f9a/attachment-0001.html>


More information about the board mailing list