Re: [OAUTH-WG] Mobile Native apps and renewing access tokens

The offline_access scope is defined as part of OpenID Connect, not as part of OAuth. There is no requirement that offline_access scope be the only way to have a refresh token issued, although some implementations have chosen to do this. My interpretation is that the offline_access is a partial

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-00.txt

Thanks for the review, George. I'll add some more color to the text around the RFC 6749 references/links so one can know what they are without having to follow the reference (or have RFC 6749 memorized :)). And adding some more guidance/discussion about the interplay of scope and resource is

Re: [OAUTH-WG] Mobile Native apps and renewing access tokens

I second the suggestion to use refresh_tokens even in an "online_access" model. You are correct that most Authorization Servers will grant offline_access to mobile apps because that produces a better user experience. However, if your requirements prohibit granting offline_access to the mobile

Re: [OAUTH-WG] Mobile Native apps and renewing access tokens

Hi, I'm the maintainer of AppAuth-Android, I've also cc'd William Denniss, the maintainer of AppAuth-iOS and the author of the OAuth2 for Native Apps BCP (BCP 212). We recommend using the code flow to get a refresh token in order to transparently acquire new access tokens as required, along with

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Thanks James - definitely an interesting case. I'd be sorry to see ACME and other APIs go down the route of POSTing base64 encoded blobs for all API interactions. On Mon, 3 Sep 2018 at 14:56, Manger, James wrote: > ACME >

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Then I’ll post an update within a ~week. There is one thing that could make implementing even simpler (from my experience). That is how to handle multiple signatures. Today the specification supports sharing of headers between signatures. If signatures instead are completely independent and put

Re: [OAUTH-WG] Non-repudiation for API requests and responses

Hi Samuel, Thanks for the reply, I would definitely be interested in an updated draft. Both the signing spec and the canonicalization spec seem a lot simpler than JSON-LD. It wouldn't be hard to add cleartext-jws signatures to existing JSON APIs Thanks Dave On Tue, 4 Sep 2018 at 23:33, Samuel