[Openid-specs-ab] Basic profile section 2.2.6.1

Nat Sakimura sakimura at gmail.com
Thu Jan 31 05:08:15 UTC 2013


Sorry for a later reply.

Right. And we should minimize referencing OAuth also.
Basic should be as self contained as possible.

Nat

2013/1/25 Mike Jones <Michael.Jones at microsoft.com>

>  It’s not in bitbucket – but it’s in the about-to-be-released call notes.*
> ***
>
> ** **
>
> I disagree that we should reference Messages.  The whole point of Basic
> and Implicit is for them to be self-contained.  If we were willing to tell
> people to just use Messages and Standard, we’d delete these (intentionally
> duplicative) specs.****
>
> ** **
>
> I’ll send my proposed change to the list shortly.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* openid-specs-ab-bounces at lists.openid.net [mailto:
> openid-specs-ab-bounces at lists.openid.net] *On Behalf Of *Pamela Dingle
> *Sent:* Thursday, January 24, 2013 10:42 AM
> *To:* openid-specs-ab at lists.openid.net
> *Subject:* [Openid-specs-ab] Basic profile section 2.2.6.1****
>
> ** **
>
> Hi all,****
>
> ** **
>
> We talked about basic profile section 2.2.6.1 on the call this morning,
>  and Mike agreed to add a bit more helpful text in there that echoes the
> existing recommendation in RFC 6749 section 3.2 on using the authorization
> header to authenticate the client vs. including client credentials in the
> post body of the request sent to the endpoint.****
>
> ** **
>
> On reading further, I think we could instead state that the possible ways
> that the client can authenticate to the Access Token Endpoint are listed in
> the Messages spec section 2.2.1, and that if a client is unsure which
> client authentication methods are supported, they can refer to a given
> openid provider's openid-configuration document, under the
> token_endpoint_auth_methods_supported element (described in Discovery
> section 3.2).    The nice thing about referring to the messages and
> discovery specs rather than directly to the OAuth spec is that it
> introduces our simple vocabulary for the different types of client
> authentication, gives us a place to insert more guidance in the future, and
> also ties in the relationship with the discovery doc, so that if a
> developer wants to be more sophisticated they know where to look.****
>
> ** **
>
> Mike, if you've got something in bitbucket for this change let me know and
> I'll put this into the ticket rather than into email, I just wanted to get
> this on the record before I forgot.****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pamela****
>
> ** **
>
> ** **
>
> --
> *Pamela Dingle*  |  Sr. Technical Architect
> *Ping**Identity*  |   www.pingidentity.com
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
> *O:* 303-999-5890   *M:* 303-999-5890
> *Email:* pdingle at pingidentity.com
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -****
>
> *Connect with Ping*
> Twitter: @pingidentity
> LinkedIn Group: Ping's Identity Cloud
> Facebook.com/pingidentitypage****
>
> *Connect with me*
> Twitter: @pamelarosiedee****
>
> ** **
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130131/e2457804/attachment.html>


More information about the Openid-specs-ab mailing list