[OpenID] Does Application Type correspond to Client Type?

Sun May 11 17:59:25 UTC 2014

This list is for general information about openID.

The correct place to discuss deployment and interop issues and questions is OpenID Connect Interop
That group/list has no IPR restrictions.

For discussing errata or other issues with the Connect specifications the list is http://lists.openid.net/mailman/listinfo/openid-specs-ab.
You must sign a non assert IPR agreement to contribute to the specification, as all the other WG participants have.

The Connect WG page lists the links and other useful information http://openid.net/connect/

The version of Dynamic Client registration being developed by the OAuth WG in the IETF based on the Connect specification can be discussed at:
https://www.ietf.org/mailman/listinfo/oauth

To your question Registration's application type is not the same as RFC 6749 Sec 2.1 Client Types.

It is dynamic registration itself that allows a native app to be confidential so that section of RFC 6749 may be changed after the IETF approves dynamic client registration.

That section also states

A client may be implemented as a distributed set of components, each
   with a different client type and security context (e.g., a
   distributed client with both a confidential server-based component
   and a public browser-based component).

Connect supports this with the hybrid response types.

A Web application with a single client_id  may contain both a public component and a confidential component.  

The element response_type determines the flows the client can preform.

The default for that is the client can only preform the code flow and must use a client credential to authenticate itself to the token endpoint.

The response types are a finer grained and imply public and private for the hybrid components.

What is not possible without extending dynamic client registration are public clients that use a code grant_type.
One of the main reasons for dynamic client registration is to eliminate the need for an AS to support public clients using the code grant_type.

In any event we can continue this on one of the other lists.

John B.

On May 11, 2014, at 6:56 PM, Takahiko Kawasaki <daru.tk at gmail.com> wrote:

> Thank you for your comment.
> 
> If both native clients and web clients can be public or confidential,
> application_type which is described in Client Metadata section of
> OpenID Connect Dynamic Client Registration 1.0 is DIFFERENT from the
> client type described in RFC 6749.
> 
> Considering the following two points:
> 
>   (1) RFC 6749 (OAuth 2.0) requires a client type to be registered.
>       (RFC 6749, 2. Client Registration)
> 
>   (2) OpenID Connect Relying Party is a kind of OAuth 2.0 client app.
>       (OpenID Connect Core 1.0, 1.2. Terminology)
> 
> there should be a client metadata entry to specify a client type (e.g.
> client_type), and it should be treated separately from application_type.
> 
> Information about Client Type (not Application Type) is really needed
> to implement OAuth 2.0 authorization server correctly. Especially it
> is needed to determine (1) whether client authentication is required
> at the token endpoint (3.2.1. Client Authentication) and (2) whether
> registration of redirect URIs can be omitted (3.1.2.2. Registration
> Requirements).
> 
> Without a client metadata entry to specify a client type, the default
> value of client type cannot help but be left to implementations of
> OpenID Connect Dynamic Client Registration 1.0.
> 
> IMHO, if such an entry (e.g. client_type) should be added, 'public'
> would be appropriate as the default value because 'client_secret' in
> Client Registration Response is OPTIONAL.
> 
> --
> Best Regards,
> Takahiko Kawasaki
> 
> 
> 
> 
> 2014-05-11 5:54 GMT+09:00 John Bradley <ve7jtb at ve7jtb.com>:
> Native clients may also be confidential if they register a unique client_id and have a secret that is provisioned in registration or out of band in some way.
> 
> Web includes both confidential and public types of clients.
> 
> Client type web or native came from a number of IdP like Google who do not allow the same client_id to be used across different types of clients.
> 
> The type of client restricts the type of redirect_uri that is allowed to be registered.
> 
> All clients must register full redirect URI and the Authorization server must match the registered redirect_uri with the one in the request.
> 
> The recent covert redirect furor and the consequences of Facebook not requiring it should go some way to explaining why registering redirect_uri is important.
> 
> One reason for not allowing native_apps and back end Web servers to share a client_id is privacy.   A user granting a app on there phone access to a API is not the same as
> granting a Web site access, and a user discovering that consenting to one automatically consented to the other may not be taken well.
> 
> The reason for separating the two types of clients is both good security and good privacy policy.
> 
> John B.
> 
> 
> On May 10, 2014, at 12:02 PM, Takahiko Kawasaki <daru.tk at gmail.com> wrote:
> 
> > If "Native Clients" in "OpenID Connect Dynamic Client Registration
> > 1.0, 2. Client Metadata" means "native application" in "RFC 6749
> > (OAuth 2.0), 2.1 Client Types" (yes it apparently does), "Native
> > Clients" are always 'public' clients.
> >
> > If "Web Clients" in "OpenID Connect Dynamic Client Registration 1.0,
> > 2. Client Metadata" means "web application" in "RFC 6749 (OAuth 2.0),
> > 2.1 Client Types" but does not include "user-agent-based application",
> > "Web Clients" are always 'confidential' clients.
> >
> > Using the above interpretation, application_type=native and
> > application_type=web correspond to 'public' and 'confidential',
> > respectively.
> >
> > However, the requirement of application_type:
> >
> >    Web Clients using the OAuth Implicit Grant Type MUST only
> >    register URLs using the https scheme as redirect_uris; they
> >    MUST NOT use localhost as the hostname. Native Clients MUST
> >    only register redirect_uris using custom URI schemes or URLs
> >    using the http: scheme with localhost as the hostname.
> >
> > is irrelevant to whether or not clients are "capable of maintaining
> > the confidentiality of their credentials" (from RFC 6749). In other
> > words, redirect URIs are irrelevant to how to authentication clients.
> > Therefore, it sounds to me that Application Type and Client Type are
> > different concepts.
> >
> > It is weird that all "OAuth 2.0 clients" must comply with either of
> > the 'redirect_uris' requirements (one is for Web Clients and the
> > other is for Native Clients), so probably it is inappropriate that
> > 'web' is used as the default value when application_type is omitted.
> > IMHO, neither of 'native' nor 'web' should be assumed when
> > application_type is omitted. But, I may be missing something. Is
> > there any reason to impose the 'redirect_uris' requirements on all
> > "OpenID Connect clients"?
> >
> > Anyway, my conclusion is that Application Type and Client Type are
> > different. And I hope that client_type (public or confidential) is
> > added to the list of Client Metadata and that neither of 'native'
> > nor 'web' is used as the default value when application_type is not
> > contained in client registration requests.
> >
> > --
> > Best Regards,
> > Takahiko Kawasaki
> >
> >
> > 2014-05-10 10:29 GMT+09:00 Takahiko Kawasaki <daru.tk at gmail.com>:
> >> Hello,
> >>
> >> I'm wondering whether this is the right place to ask my question.
> >> If not, please tell me so.
> >>
> >> I posted a question to StackOverflow, but no answer yet.
> >>
> >>  http://stackoverflow.com/q/23557801/1174054
> >>
> >> My question is "Does Application Type (OpenID Connect) correspond to
> >> Client Type (OAuth 2.0)?" Could anyone give me an answer please?
> >> Below is the detail of the question.
> >>
> >> "OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata"
> >> has an entry named application_type, whose defined values are
> >> 'native' and 'web'.
> >>
> >>  --- Excerpt from OpenID Connect Dynamic Client Registration ------
> >>  application_type
> >>    OPTIONAL. Kind of the application. The default, if omitted, is
> >>    web. The defined values are native or web. Web Clients using the
> >>    OAuth Implicit Grant Type MUST only register URLs using the
> >>    https scheme as redirect_uris; they MUST NOT use localhost as
> >>    the hostname. Native Clients MUST only register redirect_uris
> >>    using custom URI schemes or URLs using the http: scheme with
> >>    localhost as the hostname. Authorization Servers MAY place
> >>    additional constraints on Native Clients. Authorization Servers
> >>    MAY reject Redirection URI values using the http scheme, other
> >>    than the localhost case for Native Clients. The Authorization
> >>    Server MUST verify that all the registered redirect_uris conform
> >>    to these constraints. This prevents sharing a Client ID across
> >>    different types of Clients.
> >>  ------------------------------------------------------------------
> >>
> >> Do these defined values correspond to 'public' and 'confidential'
> >> described in "RFC 6749 (OAuth 2.0), 2.1. Client Types"?
> >>
> >>  --- Excerpt from RFC 6749 (OAuth 2.0) ----------------------------
> >>  OAuth defines two client types, based on their ability to
> >>  authenticate securely with the authorization server (i.e., ability
> >>  to maintain the confidentiality of their client credentials):
> >>
> >>    confidential
> >>      Clients capable of maintaining the confidentiality of their
> >>      credentials (e.g., client implemented on a secure server with
> >>      restricted access to the client credentials), or capable of
> >>      secure client authentication using other means.
> >>
> >>    public
> >>      Clients incapable of maintaining the confidentiality of their
> >>      credentials (e.g., clients executing on the device used by the
> >>      resource owner, such as an installed native application or a
> >>      web browser-based application), and incapable of secure client
> >>      authentication via any other means.
> >>  ------------------------------------------------------------------
> >>
> >> If not, why doesn't the specification (OpenID Connect Dynamic Client
> >> Registration 1.0) have an entry to specify a client type? Is there
> >> any way to specify a client type (public or confidential) at the
> >> client registration endpoint?
> >>
> >>
> >> --
> >> Best Regards,
> >> Takahiko Kawasaki
> > _______________________________________________
> > general mailing list
> > general at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-general
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20140511/56da75cf/attachment.html>