OK if there is a real use case for per request privacy policy. I think we need it in the RP XRDS for unsolicited assertions and active selectors.
I can see overriding a default privacy policy with one in the request. I suspect that >90% of the RPs are just going to have one and can reduce there request size by not putting it in the request. I did say re-using the sreg parameter would work but I am not super comfortable with using a parameter from one extension in another. I don't think that is a good practice. It would be expedient though. John B. On 2009-11-16, at 8:03 PM, Nat Sakimura wrote: > > Inline: > > On Tue, Nov 17, 2009 at 2:30 AM, John Bradley <[email protected]> wrote: > We don't have it in the request now. > > SREG does send it in openid.sreg.policy_url. > > > I would prefer to only add one new way. Adding two and deprecating one > immediately sounds a touch silly. > > If someone can think of a reason why passing it in the request is better I > would be more interested in considering it. > > Depending on what you are requesting, you might want to change the privacy > policy. Indeed, in Japanese and I believe EU privacy law, you need to be so > specific to the point that a general statement url given in XRDS probably > does not work. For instance, stating that you are "using the data for > marketing purpose" is too broad and illegal. This kind of consideration > actually rules out the discovery way of doing it. The policy is linked to the > request, and not the host/domain/company etc. > > > We know it is worse because it could be spoofed with an unsigned request. > > I anticipate that in openid v.next, the requests are going to be signed. > In the artifact binding proposal that I wrote, it is signed. > > > Unless we are proposing using openid.sreg.policy_url for both we wind up with > RP's sending the privacy policy URI twice in every request. We could reuse > the same parameter for SRAG and AX but that is not too clean. > > For short names if we want to keep with URI we could use URN eg. > urn:ax:fullname > > Though I don't give us much of a chance of getting the IANA to register a NID > for us. > > I am slightly uncomfortable making it a space separated list of strings and > URI. > > RP's code may need to be reworked to allow strings. > > The unregistered URI scheme ax: is also possible. It just depends on who we > want mad at us:) > > I suppose we could use ax:fullname and call it a string that just happens to > look like a URI:) > > John B. > On 2009-11-16, at 1:45 PM, Breno de Medeiros wrote: > > > On Sat, Nov 14, 2009 at 7:15 PM, Nat <[email protected]> wrote: > >> I am taking a crack at editing the spec. > >> > >> Observing the discussion, there are couple of questions I would like to > >> ask. > >> > >> 1. Privacy Policy URL. > >> > >> We are discussing about the privacy policy URL in RP XRD. That's fine but > >> we might also want to consider it being included in the request parameter > >> as > >> in SREG. Do you want to drop it? I think we should keep it. > > > > We could keep it for parity with SREG but recommend using discovery instead. > > > >> > >> 2. Default Attributes > >> > >> Do we want to do it in AX way or creat a special set which is compatible > >> with SREG so that the request URL will be a little shorter? > > > > +1 for introducing bult-in aliases for the commonly used URLs. > > > >> > >> =...@tokyo via iPhone > >> > >> On 2009/11/14, at 12:29, Allen Tom <[email protected]> wrote: > >> > >>> Let's just keep it simple, and put a single link for the privacy policy in > >>> the discovery document, which would be enough to have parity with SREG. A > >>> link for ToS is fine too. > >>> > >>> The UI Extension is going to define a discovery mechanism for RPs and OPs > >>> to publish their icons (and presumably their names/descriptions) so we > >>> should try to make it consistent. > >>> > >>> > >>> http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/openid-user-interface-extension-1_0.html#anchor6 > >>> > >>> Allen > >>> > >>> > >>> John Bradley wrote: > >>>> > >>>> We could do a template for lang and jurisdiction. > >>>> > >>>> The other way of dealing with lang is is via content negotiation or links > >>>> in the HTML documents. > >>>> > >>>> I don't know that it is worth complicating the simple case with > >>>> templates. > >>>> > >>>> Having different elements is also a path to madness. > >>>> > >>>> Is this a feature that OP would use? > >>>> > >>>> John B. > >>>> On 2009-11-13, at 11:30 PM, Allen Tom wrote: > >>>> > >>>>> Keeping the request size small and having RPs implement discovery are > >>>>> both good things. > >>>>> > >>>>> Also privacy policies, as well as other RP metadata (icons, > >>>>> descriptions) all make sense to put into discovery. > >>>>> > >>>>> If the RP is behind a firewall and isn't accessible to the OP, then > >>>>> hopefully OPs that care about RP metadata can just indicate to the user > >>>>> that > >>>>> the metadata was not found. > >>>>> > >>>>> The proposed XRDS schema looks reasonable. We might want to have > >>>>> different urls for different languages/jurisdictions, although that's > >>>>> probably overkill. > >>>>> > >>>>> Allen > >>>>> > >>>>> > >>>>> John Bradley wrote: > >>>>>> > >>>>>> See folks spec work can be fun:) > >>>>>> > >>>>>> John B. > >>>>>> On 2009-11-13, at 10:29 PM, Breno de Medeiros wrote: > >>>>>> > >>>>>>> Going once, going twice ... > >>>>>>> > >>>>>>> On Fri, Nov 13, 2009 at 5:26 PM, John Bradley > >>>>>>> <[email protected]> wrote: > >>>>>>>> > >>>>>>>> Any preference for a namespace? > >>>>>>>> > >>>>>>>> We could reuse the openid one that we have for openID 1.1 delegate. > >>>>>>>> > >>>>>>>> xmlns:openid="http://openid.net/xmlns/1.0"; > >>>>>>>> > >>>>>>>> <Service> > >>>>>>>> <Type>http://specs.openid.net/auth/2.0/return_to</Type> > >>>>>>>> <URI>http://consumer.example.com/return</URI> > >>>>>>>> > >>>>>>>> <openid:Policy_url>http://example.com/privacy-policy.html</openid:Policy_url> > >>>>>>>> <openid:TOS>http://example.com/terms-of-service.html</openid:TOS> > >>>>>>>> </Service> > >>>>>>>> > >>>>>>>> I should note that this wont work for RP's behind a firewall being > >>>>>>>> accessed > >>>>>>>> from a LAN or VPN. > >>>>>>>> > >>>>>>>> I am going to observe that if you are all ready on the LAN the > >>>>>>>> privacy > >>>>>>>> policy can be dealt with out of band if necessary. > >>>>>>>> > >>>>>>>> I am not emotionally attached to the namespace or element names if > >>>>>>>> someone > >>>>>>>> has something else they like. > >>>>>>>> > >>>>>>>> John B. > >>>>>>>> On 2009-11-13, at 9:51 PM, Breno de Medeiros wrote: > >>>>>>>> > >>>>>>>>>> > >>>>>>>>>> While we are at it do we want to also publish a TOS URI? > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> Don't see why not. > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> --Breno > >>>>>>>>> > >>>>>>>>> +1 (650) 214-1007 desk > >>>>>>>>> +1 (408) 212-0135 (Grand Central) > >>>>>>>>> MTV-41-3 : 383-A > >>>>>>>>> PST (GMT-8) / PDT(GMT-7) > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> --Breno > >>>>>>> > >>>>>>> +1 (650) 214-1007 desk > >>>>>>> +1 (408) 212-0135 (Grand Central) > >>>>>>> MTV-41-3 : 383-A > >>>>>>> PST (GMT-8) / PDT(GMT-7) > >>>>>> > >>>>> > >>>> > >>> > >>> _______________________________________________ > >>> specs mailing list > >>> [email protected] > >>> http://lists.openid.net/mailman/listinfo/openid-specs > >> > >> _______________________________________________ > >> specs mailing list > >> [email protected] > >> http://lists.openid.net/mailman/listinfo/openid-specs > >> > > > > > > > > -- > > --Breno > > > > +1 (650) 214-1007 desk > > +1 (408) 212-0135 (Grand Central) > > MTV-41-3 : 383-A > > PST (GMT-8) / PDT(GMT-7) > > _______________________________________________ > > specs mailing list > > [email protected] > > http://lists.openid.net/mailman/listinfo/openid-specs > > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
