Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery

From: Anthony Nadalin <[email-masked]>
Date: Thu, 28 Oct 2010 15:07:24 +0000

Sampo, can you give a usecase of how you would use the pairwise

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 26, 2010 6:40 PM
To: Mike Jones
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery

Simple enough spec. I like the notion of service type. However some questions to answer:

How would one convey saml2:Assertion as the "principal"? Or how would one convey a saml2:NameID as the "principal"?

Or in more generic sense, how would one convey a pairwise pseudonym as principal?

Cheers,
--Sampo

Mike Jones <[email-masked]> said:
> Having a simple discovery method for services and resources is key to enabling many Internet scenarios that require interactions among parties that do not have pre-established relationships.  For instance, if Joe, with e-mail address [email-masked], wants to share his calendar with Mary, then Mary's calendar service, in the general case, will need to discover the location of Joe's calendar service.  For example, Mary's calendar service might discover that Joe's calendar service is located at http://calendars.proseware.com/calendar/joseph by doing discovery for a service named urn:adatum.com:calendar  at example.com for the account joe.
> 
> Yaron Goland<http://www.goland.org/> and I are submitting this Simple Web Discovery (SWD)<http://self-issued.info/docs/draft-jones-simple-web-discovery-00.html> draft (attached and at http://self-issued.info/docs/draft-jones-simple-web-discovery-00.html) for consideration by the community to address this need.  SWD is simple to understand and implement, enables different permissions to be applied to discovery of different services, and is JSON-based.  I look forward to discussing this with many of you next week at IIW<http://www.internetidentityworkshop.com/iiwxi-11-in-mountain-view/>.
> 
>                                                                 -- 
> Mike
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
> 
_______________________________________________
Openid-specs-ab mailing list
[email-masked]
http://lists.openid.net/mailman/listinfo/openid-specs-ab

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Oct 2010 12:40:58 -0300

In the case where the user logs in to a RP with a PPID type identifier.  

How could the person then allow the RP to discover their service endpoints.
Also conversely would publishing the endpoint provide a way for the RP to correlate the user without permission.

One common practice for openID PPID is that the IdP generates the PPID via AES128(actual ID + RP or sector identifier).

In that case the RP could do an oauth flow to the IdP discovery endpoint to get permission to see the user endpoints.
The IdP could decrypt the opaque identifier to determine the actual subject.

That would protect the non correlation unless the user decides to permit discovery.

The model if not the details seem similar to some work that is being submitted to the ITU-T as I understand it.

John B.

On 2010-10-28, at 12:07 PM, Anthony Nadalin wrote:

> openid-specs-connect mailing list
> [email-masked]
> http://lists.openid.net/mailman/listinfo/openid-specs-connect

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 28 Oct 2010 23:42:31 +0000

So not sure that this would be handled by the SWD itself but as pointed out in the SWD specification is that the SWD may be accompanied by an authorization header and this is where I would expect that to happen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Thursday, October 28, 2010 8:41 AM
To: the Connect work group
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery

John B.

On 2010-10-28, at 12:07 PM, Anthony Nadalin wrote:

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Oct 2010 21:22:24 -0300

If there is no authorization mechanism,  then this is just a JSON version of XRD.  

Not that you couldn't add authorization to XRD.

We were planning on doing that as an option for a proxy resolution flow that would look quite similar.

The way that the existing XRI resolver works is quite similar to what you describe filtering by service.
One of the use cases has been adding authentication, but there was never enough interest.

Too bad MS didn't participate in XRD.

John B.

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 29 Oct 2010 15:57:21 +0000

I would not say that this is just a JSON version of XRD, as XRD has quite a few more complex feature. What is being suggested here is being able to use OAuth for the authorization/delegation to discovery information in a very simple chunkable forward means.

-----Original Message-----
From: John Bradley [mailto:[email-masked]] 
Sent: Thursday, October 28, 2010 5:22 PM
To: Anthony Nadalin
Cc: the Connect work group; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Openid-specs-ab] [OAUTH-WG] Simple Web Discovery

John B.

---

From: John Bradley <[email-masked]>
Date: Fri, 29 Oct 2010 13:13:20 -0300

I am agreeing using oAuth in that way is a good idea.   It has been discussed various places.  I think Eve's UMA group is looking at some options for that.

You could however do the same thing with WebFinger/XRD.

It would have been better to have worked on this together over the last year and a half.

However we are where we are and we need to look at it as a legitimate proposal.

However it will be up against other similar work in the community.

John B.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 29 Oct 2010 09:24:23 -0700

Can you list those "quite a few more complex feature"?

XRD (and JRD) were carefully balanced over 3 years to produce a simple specification that covers basic discovery needs without any unnecessary complexity. It was coordinated with IETF, OASIS, OpenID, and W3C efforts, and successfully adopted by new lightweight protocols. To invent yet another format that is clearly overlapping without even trying to engage in the XRD/JRD work is poor community participation.

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Anthony Nadalin
> Sent: Friday, October 29, 2010 8:57 AM
> To: John Bradley
> Cc: [email-masked]; [email-masked]; the Connect work
> group; [email-masked]
> Subject: Re: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery
> 
> I would not say that this is just a JSON version of XRD, as XRD has quite a few
> more complex feature. What is being suggested here is being able to use
> OAuth for the authorization/delegation to discovery information in a very
> simple chunkable forward means.
> 
> > So not sure that this would be handled by the SWD itself but as
> > pointed out in the SWD specification is that the SWD may be
> > accompanied by an authorization header and this is where I would
> > expect that to happen
> >
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of
> > John Bradley
> > One common practice for openID PPID is that the IdP generates the PPID
> via AES128(actual ID + RP or sector identifier).
> >
> > In that case the RP could do an oauth flow to the IdP discovery endpoint to
> get permission to see the user endpoints.
> > The model if not the details seem similar to some work that is being
> submitted to the ITU-T as I understand it.
> >
> > John B.
> >
> >
> >> Cc: [email-masked]; [email-masked];
> >> [email-masked]; [email-masked]
> >> How would one convey saml2:Assertion as the "principal"? Or how would
> one convey a saml2:NameID as the "principal"?
> >>
> >>> Having a simple discovery method for services and resources is key to
> enabling many Internet scenarios that require interactions among parties
> that do not have pre-established relationships.  For instance, if Joe, with e-
> mail address [email-masked], wants to share his calendar with Mary, then
> Mary's calendar service, in the general case, will need to discover the location
> of Joe's calendar service.  For example, Mary's calendar service might
> discover that Joe's calendar service is located at
> http://calendars.proseware.com/calendar/joseph by doing discovery for a
> service named urn:adatum.com:calendar  at example.com for the account
> joe.
> >>>
> >>> Yaron Goland<http://www.goland.org/> and I are submitting this Simple
> Web Discovery (SWD)<http://self-issued.info/docs/draft-jones-simple-web-
> discovery-00.html> draft (attached and at http://self-issued.info/docs/draft-
> jones-simple-web-discovery-00.html) for consideration by the community to
> address this need.  SWD is simple to understand and implement, enables
> different permissions to be applied to discovery of different services, and is
> JSON-based.  I look forward to discussing this with many of you next week at
> IIW<http://www.internetidentityworkshop.com/iiwxi-11-in-mountain-
> view/>.
> >>>
> >>>                                                               --
> >>> Mike
> >>>

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 29 Oct 2010 16:37:03 +0000

Like an XML parser

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Friday, October 29, 2010 9:24 AM
To: Anthony Nadalin; John Bradley
Cc: [email-masked]; [email-masked]; the Connect work group; [email-masked]
Subject: RE: [OAUTH-WG] [Openid-specs-ab] Simple Web Discovery

EHL

> Cc: [email-masked]; [email-masked]; the Connect 
> work group; [email-masked]
> I would not say that this is just a JSON version of XRD, as XRD has 
> quite a few more complex feature. What is being suggested here is 
> being able to use OAuth for the authorization/delegation to discovery 
> information in a very simple chunkable forward means.
> 
> > [email-masked]
> > Also conversely would publishing the endpoint provide a way for the 
> > RP to
> correlate the user without permission.
> >
> > That would protect the non correlation unless the user decides to 
> > permit
> discovery.
> >
> enabling many Internet scenarios that require interactions among 
> parties that do not have pre-established relationships.  For instance, 
> if Joe, with e- mail address [email-masked], wants to share his 
> calendar with Mary, then Mary's calendar service, in the general case, 
> will need to discover the location of Joe's calendar service.  For 
> example, Mary's calendar service might discover that Joe's calendar 
> service is located at http://calendars.proseware.com/calendar/joseph 
> by doing discovery for a service named urn:adatum.com:calendar  at 
> example.com for the account joe.
> >>>
> Web Discovery 
> (SWD)<http://self-issued.info/docs/draft-jones-simple-web-
> jones-simple-web-discovery-00.html) for consideration by the community 
> to address this need.  SWD is simple to understand and implement, 
> enables different permissions to be applied to discovery of different 
> services, and is JSON-based.  I look forward to discussing this with 
> many of you next week at

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 29 Oct 2010 09:40:35 -0700

JRD does not require an XML parser. If you want to talk about simplicity, "engage" is simpler than "reinvent".

EHL

> From: Anthony Nadalin [mailto:[email-masked]]
> Sent: Friday, October 29, 2010 9:37 AM
> To: Eran Hammer-Lahav; John Bradley
> XRD (and JRD) were carefully balanced over 3 years to produce a simple
> specification that covers basic discovery needs without any unnecessary
> complexity. It was coordinated with IETF, OASIS, OpenID, and W3C efforts,
> and successfully adopted by new lightweight protocols. To invent yet
> another format that is clearly overlapping without even trying to engage in
> the XRD/JRD work is poor community participation.
> 
> EHL
> 
> > >> Or in more generic sense, how would one convey a pairwise
> pseudonym
> > as principal?
> > >>
> > >> Cheers,
> > >> --Sampo
> > >>