Yes we should have a look at RP Libs. So AX currently uses: openid.ax.type.fname=http://example.com/schema/fullname
We could allow: openid.ax.type.fname=fullname Though that may break some string handling. We could still use a URI safe string like: openid.ax.type.fname=ax:fullname This would NOT be a URI but would be less likely to break existing parsers and string handling. Any ideas other than a code review? John B. On 2009-11-16, at 3:24 PM, Breno de Medeiros wrote: > 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)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
