On 26-Sep-06, at 4:13 PM, Josh Hoyt wrote:
>> Pass-through (or "echo") parameters and potentially some OpenID
>> extension parameters may include fields with multiple values in order
>> to communicate arrays of data, etc.
>
> Attribute exchange and other extensions can *easily* be designed not
> t
On 26-Sep-06, at 4:13 PM, Josh Hoyt wrote:
> On 9/26/06, Barry Ferg <[EMAIL PROTECTED]> wrote:
>> The signature generation algorithm specifies that the fields to be
>> signed be ordered in byte order form. It seems to be implied that
>> the ordering is based on using the field names as sorting ke
On 26-Sep-06, at 4:53 PM, Josh Hoyt wrote:
> On 9/26/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
>> You can use either HTTP_RAW_POST_DATA or reading from
>> php://input, this gives you the url encoded list of parameters.
>> Parsing this is trivial.
>>
>
Yes, you can work around the limitation. But why introduce a
limitation for something widely used and then work around it?
Marius
On 27-Sep-06, at 7:43 AM, David Fuelling wrote:
> Just for clarification -- if duplicate parameters of the same name
> are NOT
> allowed by the spec, would one st
On 27-Sep-06, at 10:09 AM, Josh Hoyt wrote:
> On 9/27/06, Barry Ferg <[EMAIL PROTECTED]> wrote:
>> For that matter, isn't having implementation issues in certain
>> restrictive development environments drive the specification kind of
>> like the tail wagging the dog?
>
> I am attempting to be prag
On 27-Sep-06, at 11:10 AM, Johannes Ernst wrote:
> On Sep 27, 2006, at 9:48, Granqvist, Hans wrote:
>
>> Johannes, just to clarify, are you against allowing
>> multiple same-name params?
>
> I don't like multi-valued fields, because in my experience, it is a
> slippery slope that usually leads s
On 27-Sep-06, at 12:18 PM, Josh Hoyt wrote:
> On 9/27/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
>> It is quite common (and natural) to use multi-valued fields for check
>> boxes and multi select list boxes.
>
> But browsers (the things that do HTML form submissio
On 27-Sep-06, at 12:22 PM, Johannes Ernst wrote:
> On Sep 27, 2006, at 12:08, Marius Scurtescu wrote:
>
>> Multi-valued fields represent lists. Lists are very useful data
>> structures, and yes, lists can be misused/abused.
>
> Now you are knocking down the wrong stra
I think that the proposal made by Josh makes sense.
First of all, why would you hide the claimed identifier from the IdP?
If you don't trust your IdP you should not use it. Same thing if the
IdP tries to charge you more because you are using delegate
identifiers. If it is unreasonable then m
On 5-Oct-06, at 3:36 PM, Recordon, David wrote:
> Conceptually I think I like this model. It does seem easier to
> understand.
>
> Other thoughts on this?
I am still not sure how the delegated identifier is useful. I did
miss the earlier discussions, so probably I don't have enough
backgroun
On 12-Oct-06, at 12:10 PM, Recordon, David wrote:
> We thus believe that any state tracking needed by a stateless RP
> must be maintained as GET parameters within the return_to
> argument. In the case of a stateful RP, it can either do the same
> thing, or store state via other means such as
On 12-Oct-06, at 10:29 AM, Josh Hoyt wrote:
> Both portable and IdP-specific identifiers
> --
>
> Include both the portable identifier and the IdP-specific identifier
> in the request and response ([4]_ and
> [5]_)::
>
> openid.identity = http://my.idp.spe
On 12-Oct-06, at 5:07 PM, Josh Hoyt wrote:
> On 10/12/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
>> If passing through all unrecognized parameters can cause problems
>> then there could be a special namespace for this purpose. For
>> example, all paramete
TECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Josh Hoyt
> Sent: Thursday, October 12, 2006 8:56 PM
> To: Marius Scurtescu
> Cc: specs@openid.net
> Subject: Re: Delegation discussion summary
>
> On 10/12/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
> >
On 12-Oct-06, at 11:47 PM, Drummond Reed wrote:
>> Marius wrote:
>>
>> I was suggesting that portability can be resolved between the user
>> and
>> the IdP. I cannot see how the protocol can help this by passing two
>> identifiers. And if only the portable identifier is passed then
>> there i
On 13-Oct-06, at 12:20 PM, Drummond Reed wrote:
Marius wrote:
I was suggesting that portability can be resolved between the user
and
the IdP. I cannot see how the protocol can help this by passing two
identifiers. And if only the portable identifier is passed then
>>>
On 13-Oct-06, at 12:59 PM, Drummond Reed wrote:
> Yesterday we established consensus that with OpenID, identifier
> portability
> is sacred.
>
> Today I'd like to establish consensus on the following "postulate":
>
> "To achieve identifier portability in OpenID, it MUST be possible
> for the
On 12-Oct-06, at 11:40 PM, Drummond Reed wrote:
>>> Drummond wrote:
>>> Since the RP has to do discovery on the i-name, the RP already
>>> has the
>>> i-number (CanonicalID). Further, as explained in previous
>>> threads, the
>>> CanonicalID is the primary key the RP wants to store for the use
On 16-Oct-06, at 12:24 PM, Martin Atkins wrote:
> Chris Drake wrote:
>>
>> There seem to be a lot of people on this list who want to hate and
>> loathe the IdP, and grant all power to the RP. I do not understand
>> this reasoning: our users will select the IdP they trust and like,
>> then they w
On 16-Oct-06, at 2:01 PM, Josh Hoyt wrote:
> On 10/16/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
>> In this case you are better off opening a separate account with this
>> or some other IdP. The current delegation model will not protect you
>> at all. The de
On 16-Oct-06, at 2:44 PM, Josh Hoyt wrote:
> On 10/16/06, Recordon, David <[EMAIL PROTECTED]> wrote:
>> 6.1 Signed List Algorithm
> [...]
>> I'm thinking it would make sense to
>> change this algorithm to first alphabetically sort the arguments
>> to make
>> it very clear in terms of ordering.
>
On 16-Oct-06, at 3:13 PM, Josh Hoyt wrote:
> On 10/16/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
>> Sorting of unicode strings while not terrible hard it is not trivial
>> either. Why bother? The list of signed fields gives an explicit
>> ordering, this is good eno
On Wed, 2007-18-04 at 21:05 -0500, Mark Wahl wrote:
> Johnny Bufu wrote:
> > The core spec doesn't allow newline characters ("\n") in any openid.*
> > values. Currently, Attribute Exchange doesn't specify a way to encode
> > newlines in attribute values.
> >
> > At a minimum, we could specify
On Wed, 2007-18-04 at 23:25 -0700, Douglas Otis wrote:
> On Apr 18, 2007, at 8:31 PM, Marius Scurtescu wrote:
>
> > Base64 encoding is a pretty good candidate for binary data, but you
> > cannot apply the same encoding to text fields.
>
> RFC4648 "URL and Filename sa
On 19-Apr-07, at 7:29 AM, Rowan Kerr wrote:
> On 18-Apr-07, at 9:47 PM, Johnny Bufu wrote:
>> The core spec doesn't allow newline characters ("\n") in any openid.*
>> values. Currently, Attribute Exchange doesn't specify a way to encode
>> newlines in attribute values.
>
> Every indirect OpenID m
On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote:
> 7.3.3. HTML-Based Discovery
>
> A tag MUST be included with attributes "rel" set to
> openid2.provider"
> and "href" set to an OP Endpoint URL
>
> A tag MAY be included with attributes "rel" set to
> "openid2.local_id"
> and "href" set to t
fast :-)
Looks good, but I would add to that a sentence stating that you
SHOULD put both sets of tags when editing HTML pages in order to be
backwards compatible.
Thanks,
Marius
>
> Thanks,
> --David
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROT
On 18-May-07, at 11:45 AM, Josh Hoyt wrote:
> On 5/18/07, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
>> On 18-May-07, at 1:00 AM, Dmitry Shechtman wrote:
>> In order to be backwards compatible the HTML page should have two
>> sets of tags one for OpenID 1.1 and one fo
28 matches
Mail list logo
