Expose the OpenID Types from ConsumerManager discover method

[GoogleCodeExporter]

Using Yadis discovery:

getConsumerManager().getDiscovery().discover(opEndpointUrl) 

calls into _yadisResolver.discover(urlId.getIdentifier(), cache);

which eventually calls into: 

 public List discover(String url, int maxRedirects, HttpCache cache)
        throws DiscoveryException
    {
        return discover(url, maxRedirects, cache, DiscoveryInformation.OPENID_OP_TYPES)
            .getDiscoveredInformation(DiscoveryInformation.OPENID_OP_TYPES);
    }

From the consumer manager api, there is no means to identify which types 
services you are attempting to discover. Given the hard coded OPENID_OP_TYPES 
it can discover BOTH the server and signon at the same time. 

For example:
<?xml version="1.0" encoding="UTF-8"?> 
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
    <XRD>
          <Service>
            <Type>http://specs.openid.net/auth/2.0/signon</Type>                  <Type>http://specs.openid.net/auth/2.0/server</Type>
            <URI>http://example.com/login</URI>
        </Service>           
    </XRD>
</xrds:XRDS>

There is an assumption in 
org.openid4java.discovery.yadis.YadisResult.getDiscoveredInformation(Set) such 
that if "http://specs.openid.net/auth/2.0/signon" is found, then the url used 
to discover that document, must be the claimed identifier. 

 if (!targetTypes.contains(type)) continue;
                    try {
                        result.add(new DiscoveryInformation(
                            new URL(endpoint.getUri()),
                            DiscoveryInformation.OPENID_SIGNON_TYPES.contains(type) ?
                                new UrlIdentifier(_normalizedUrl) : null,
                            DiscoveryInformation.OPENID2.equals(type) ? endpoint.getLocalId() :
                            DiscoveryInformation.OPENID1_SIGNON_TYPES.contains(type) ? endpoint.getDelegate() : null,
                            type,
                            endpoint.getTypes()));
                    } 

 (the second parameter is the claimed identifier, and the _normalizedUrl is the the URL of the discovery service )

 Since from the consumer manager api, there is no option to define the targetTypes, the URL of the server discovery can incorrectly be placed as the claimed identifier. Actually both the server and signon are discovered, and the signon endpoint has a claimed identifier of the discovery url, and the server endpoint's claimed identifier is correctly null.  Without additional scrubbing of the data returned, it is quite easy for the wires to be crossed and send the user to the openid provider with the claimed identifier from the signon discovery element. 

 For example, given the XRDS document above, the claimed identifier can end up as "http://example.com/discovery". 

 This is part bug, API's should be easy to use hard to abuse, and part enhancement request for the consumer manager api to allow for types to be specified on discovery.

Original issue reported on code.google.com by jl009...@gmail.com on 18 Mar 2012 at 7:25

[GoogleCodeExporter]

"There is an assumption in 
org.openid4java.discovery.yadis.YadisResult.getDiscoveredInformation(Set) such 
that if "http://specs.openid.net/auth/2.0/signon" is found, then the url used 
to discover that document, must be the claimed identifier."

The above is not an assumption, it is part of the Yadis/discovery spec.

"This is part bug, API's should be easy to use hard to abuse, and part 
enhancement request for the consumer manager api to allow for types to be 
specified on discovery."

The types are specified by the OpenID spec; all discovered types are returned 
to the API client who is free to examine and chose the ones that are relevant.

If you think this is a bug please summarize by posting a correct discovery info 
that is discovered incorrectly by OpenID4Java (and point to the specific 
sections of the Yadis spec that are violated).

Original comment by Johnny.B...@gmail.com on 19 Mar 2012 at 2:53

[GoogleCodeExporter]

>>The above is not an assumption, it is part of the Yadis/discovery spec.

Can you please point to where this is part of the Yadis/discover spec ?

>> If you think this is a bug please summarize by posting a correct discovery 
info that is discovered incorrectly by OpenID4Java (and point to the specific 
sections of the Yadis spec that are violated).

I do not believe that Yadis spec is being violated.  Also, I do not see how the 
XRDS document discovery information posted in not valid discovery information.  
It perfectly in the scope of schema, and natural fit if the signon and server 
live at the same end point.

Original comment by jl009...@gmail.com on 19 Mar 2012 at 3:10

[GoogleCodeExporter]

>>If you think this is a bug
Not necessarily, but did/do not see how log enhancements. 

Original comment by jl009...@gmail.com on 19 Mar 2012 at 3:38

[GoogleCodeExporter]

Discovery is performed on an Identifier, not on a OP Endpoint URL.

The URL on which discovery was (successfully) performed becomes the Claimed 
Identifier; the OP Endpoint URL always comes from the <URI> element.

An Identifier is either a user's Identifier or an OP Identifier, it cannot be 
both at the same time. If you list two or more types for the same 
Identifier/discovery entry, there is a precedence in which they are considered, 
see section 7.3.1.  Discovered Information.

You can configure the same OP Endpoint URL for multiple Identifiers by listing 
the same value in their discovery information, under the <URI> element.

Original comment by Johnny.B...@gmail.com on 19 Mar 2012 at 5:06

[GoogleCodeExporter]

Jake, section 11.1 states "The Claimed Identifier MUST NOT be an OP 
Identifier."  It seems arbitrary, but the specification clearly states it can't 
be both.

Original comment by matthew....@gmail.com on 28 Mar 2012 at 8:25

[GoogleCodeExporter]

It is not arbitrary: you (a user) cannot claim to be/own an OP identifier.

OP identifiers are used to initiate the identifier_select flow, where the 
user's claimed identifier is selected at the OP (as opposed to entering it at 
the RP).

Original comment by Johnny.B...@gmail.com on 28 Mar 2012 at 8:38

[GoogleCodeExporter]

Original comment by Johnny.B...@gmail.com on 31 Oct 2012 at 8:01

• Changed state: Invalid