Aaron Parecki

I do think we should make sure there is a clear path to using this for Ticket Auth before bringing it into the spec. My recollection is that is the...

The token response should match OAuth 2. * token_type=Bearer is required * scope is required if it differs from what the client requested, otherwise it's optional

I'm not sure the best path forward on this. We used underscores for `authorization_endpoint` because that's the same name as the property in [OpenID Connect Discovery](http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata). It seems that parsers...

Perhaps the way forward on this is to switch to an IndieAuth Server Metadata URL #43 and use a name that isn't disallowed for that endpoint.

Great, sounds like we generally have support for this. I merged in #138 so I'll close this now.

Do we know how many servers currently default to form-encoded responses still? I'm still on the fence about adding this since it's not a requirement of OAuth 2.0, and is...

At the very least adding the `Accept` header to the examples is a good place to start, go for it!

I'm inclined to not add text to the spec that requires or suggests sending the Accept header. Looking back at OAuth 2.0, it doesn't even include the Accept header in...

I would rather get all clients and servers to update to drop form-encoded responses completely at this point.

How does `time.entry-date[datetime]` differ in usage from `time.published[datetime]`? The couple wordpress sites I looked at had both `entry-date` and `published` on the `time` element. I'll have to think through how...