On Mon, Nov 16, 2009 at 9:30 AM, John Bradley <[email protected]> wrote: > We don't have it in the request now. > > I would prefer to only add one new way. Adding two and deprecating one > immediately sounds a touch silly.
Ok, putting it like this convinced me. Let's focus on defining the discovery-based way. > > If someone can think of a reason why passing it in the request is better I > would be more interested in considering it. > > We know it is worse because it could be spoofed with an unsigned request. > > 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:) Maybe this decision could be helped by surveying RP libraries and see what causes them to choke. > > 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 > > -- --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
