Re: 4.3. This could be something to put in security considerations. Since there will be reasonable cases where for example a password hash is retained. And as indicated by Eran, this is a best practice rather then an inter-op issue.
Phil phil.h...@oracle.com On 2011-02-16, at 8:34 AM, Eran Hammer-Lahav wrote: > > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurte...@google.com] >> Sent: Wednesday, January 26, 2011 12:09 PM > >> - 4.3. Resource Owner Password Credentials. The 3rd paragraph states that >> the client MUST discard the credentials once it obtains an access token. I >> think it SHOULD discard once it obtains a *refresh* token. > > Since this MUST cannot be confirmed, it serves as a community educational > tool more than anything else. I rather leave it without conditions. > >> - 4.5. Extensions. For new grant types, we are not using a registry. Is that >> OK? > > No need. The registry is only to prevent name collisions and since we are > using URIs, they already have built-in namespaces. > >> - 5.2. Error Response. The fist part of the first paragraph talks about 401 >> and >> client credentials in the Authorization header. Since this was dropped from >> core, this looks strange. > > This is specific to client authentication, not grant verification or > protected resources. I'll clarify. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
