Re: OPs to advertise support for OpenID extensions via the extension's type URI

[David Recordon]

Sounds good to me!

On Jul 22, 2009, at 5:23 PM, John Bradley wrote:


+1 I think that advertising the extension itself is a good practice.

A RP may prefer OPs that support the extension over ones that don't.

That is the case for PAPE now as an example.

With XRD most of that will be described in the OPs XRD rather than  
the users, but the same principal should apply.


John B.
On 22-Jul-09, at 12:00 PM, specs-requ...@openid.net wrote:


From: Breno de Medeiros 
Subject: Re: OPs to advertise support for OpenID extensions via the
    extension's type URI
To: Andrew Arnott 
Cc: specs@openid.net
Message-ID:
<29fb00360907221019t10a0393aydbae458ba8c66...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary=00151750e13a821afc046f4e91df

--00151750e13a821afc046f4e91df
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I agree with Andrew on this suggestion. I don't think the UI WG  
proceeded

differently for any particular reason, except that no such convention
existed and we were not aware of side-effects previously.  
Regardless of
interoperability issues with existing libraries, I thinking having  
a type
URI for the extension is desirable from purely semantic standpoint  
(if a
human were to read such document, it would be more logically  
organized with

'umbrella' type URIs for the extension).


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OPs to advertise support for OpenID extensions via the extension's type URI

[John Bradley]

+1 I think that advertising the extension itself is a good practice.

A RP may prefer OPs that support the extension over ones that don't.

That is the case for PAPE now as an example.

With XRD most of that will be described in the OPs XRD rather than the  
users, but the same principal should apply.


John B.
On 22-Jul-09, at 12:00 PM, specs-requ...@openid.net wrote:


From: Breno de Medeiros 
Subject: Re: OPs to advertise support for OpenID extensions via the
    extension's type URI
To: Andrew Arnott 
Cc: specs@openid.net
Message-ID:
<29fb00360907221019t10a0393aydbae458ba8c66...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary=00151750e13a821afc046f4e91df

--00151750e13a821afc046f4e91df
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I agree with Andrew on this suggestion. I don't think the UI WG  
proceeded

differently for any particular reason, except that no such convention
existed and we were not aware of side-effects previously. Regardless  
of
interoperability issues with existing libraries, I thinking having a  
type
URI for the extension is desirable from purely semantic standpoint  
(if a
human were to read such document, it would be more logically  
organized with

'umbrella' type URIs for the extension).


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OPs to advertise support for OpenID extensions via the extension's type URI

[Allen Tom]

+1

Allen


Breno de Medeiros wrote:
I agree with Andrew on this suggestion. I don't think the UI WG 
proceeded differently for any particular reason, except that no such 
convention existed and we were not aware of side-effects previously. 
Regardless of interoperability issues with existing libraries, I 
thinking having a type URI for the extension is desirable from purely 
semantic standpoint (if a human were to read such document, it would 
be more logically organized with 'umbrella' type URIs for the extension).


On Wed, Jul 22, 2009 at 4:57 PM, Andrew Arnott > wrote:


Hi folks,

Breno just pointed out to me that the UI extension's draft spec,
Discovery section
 calls
out two type URIs that should appear in an OpenID identifier's
XRDS document.  But neither of these type URIs is the type URI of
the extension itself.

DotNetOpenId and DotNetOpenAuth both take for granted that an
extension's primary type URI (the one that appears at the value of
the openid.ns./someext/ parameter) is expected to appear in an
XRDS document if the OP supports that extension.  Maybe that
wasn't a spec'd out behavior for OpenID extensions, but it seems
to hold true for the OPs I tested at the time. 


While it's neat to see the UI extension include a specific
Discovery section that allows OPs to declare their support for the
different parts of the extension, there's no mention of declaring
the extension itself.  As a result, RPs (at least the ones based
on DNOI/DNOA) may not think that an OP supports the UI extension
when in fact it does.  


So I'm requesting two things:

   1. Can we get the UI extension DRAFT spec updated to include
  that the http://specs.openid.net/extensions/ui/1.0 URI be
  included in the XRDS document?
   2. Can we standardize on the idea that an extension's type URI
  should be in an XRDS document if the OP supports it so that
  RPs can easily scan for all supported extensions? (this
  would be in addition to any additional type URIs the
  extension wants to define and advertise)

What do you all think?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to
the death your right to say it." - S. G. Tallentyre

___
specs mailing list
specs@openid.net 
http://openid.net/mailman/listinfo/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
specs@openid.net
http://openid.net/mailman/listinfo/specs
  


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OPs to advertise support for OpenID extensions via the extension's type URI

[Breno de Medeiros]

I agree with Andrew on this suggestion. I don't think the UI WG proceeded
differently for any particular reason, except that no such convention
existed and we were not aware of side-effects previously. Regardless of
interoperability issues with existing libraries, I thinking having a type
URI for the extension is desirable from purely semantic standpoint (if a
human were to read such document, it would be more logically organized with
'umbrella' type URIs for the extension).

On Wed, Jul 22, 2009 at 4:57 PM, Andrew Arnott wrote:

> Hi folks,
> Breno just pointed out to me that the UI extension's draft spec, Discovery
> section 
> calls
> out two type URIs that should appear in an OpenID identifier's XRDS
> document.  But neither of these type URIs is the type URI of the extension
> itself.
>
> DotNetOpenId and DotNetOpenAuth both take for granted that an extension's
> primary type URI (the one that appears at the value of the openid.ns.*
> someext* parameter) is expected to appear in an XRDS document if the OP
> supports that extension.  Maybe that wasn't a spec'd out behavior for OpenID
> extensions, but it seems to hold true for the OPs I tested at the time.
>
> While it's neat to see the UI extension include a specific Discovery
> section that allows OPs to declare their support for the different parts of
> the extension, there's no mention of declaring the extension itself.  As a
> result, RPs (at least the ones based on DNOI/DNOA) may not think that an OP
> supports the UI extension when in fact it does.
>
> So I'm requesting two things:
>
>1. Can we get the UI extension DRAFT spec updated to include that the
>http://specs.openid.net/extensions/ui/1.0 URI be included in the XRDS
>document?
>2. Can we standardize on the idea that an extension's type URI should
>be in an XRDS document if the OP supports it so that RPs can easily scan 
> for
>all supported extensions? (this would be in addition to any additional type
>URIs the extension wants to define and advertise)
>
> What do you all think?
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/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
specs@openid.net
http://openid.net/mailman/listinfo/specs

OPs to advertise support for OpenID extensions via the extension's type URI

[Andrew Arnott]

Hi folks,
Breno just pointed out to me that the UI extension's draft spec, Discovery
section 
calls
out two type URIs that should appear in an OpenID identifier's XRDS
document.  But neither of these type URIs is the type URI of the extension
itself.

DotNetOpenId and DotNetOpenAuth both take for granted that an extension's
primary type URI (the one that appears at the value of the openid.ns.*
someext* parameter) is expected to appear in an XRDS document if the OP
supports that extension.  Maybe that wasn't a spec'd out behavior for OpenID
extensions, but it seems to hold true for the OPs I tested at the time.

While it's neat to see the UI extension include a specific Discovery section
that allows OPs to declare their support for the different parts of the
extension, there's no mention of declaring the extension itself.  As a
result, RPs (at least the ones based on DNOI/DNOA) may not think that an OP
supports the UI extension when in fact it does.

So I'm requesting two things:

   1. Can we get the UI extension DRAFT spec updated to include that the
   http://specs.openid.net/extensions/ui/1.0 URI be included in the XRDS
   document?
   2. Can we standardize on the idea that an extension's type URI should be
   in an XRDS document if the OP supports it so that RPs can easily scan for
   all supported extensions? (this would be in addition to any additional type
   URIs the extension wants to define and advertise)

What do you all think?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs