puiterwijkso let me summarize:11:32
puiterwijkin OAuth, there is defined a protected resource, this is the function you want to call or the data you want to retrieve11:33
puiterwijkyou also have the resource server, this is the server hosting the resource11:33
puiterwijkthen the client, this is the application that wants to access the resource hosted on the resource server11:34
puiterwijknext up we have the resource owner: the user or system that's authorized to give clients access to the resource. for example: the resource owner for the resource "full name of puiterwijk" hosted on resource server FAS would be me11:35
puiterwijkand we have the authorization server (the first role that does not include "resource" :)), which is the server that grants tokens and codes11:35
puiterwijklet me skip a bit to the part which we have been discussing so far: oauth has an "access token", which is based of a client-id and a client-secret which gives access to the resource on the authority of the resource owner by the client11:36
puiterwijks/by the client/to the client/11:37
abadger1999okay -- I think I'll need an example to understand how the  resource server, authorization server, and resource owner relate later.11:37
puiterwijkabadger1999: okay, I can give an example11:38
puiterwijkresource: the full name of "puiterwijk"11:38
puiterwijkresource server: FAS11:38
puiterwijkresource owner: puiterwijk11:38
puiterwijkauthorization server: FAS-OpenID (by example)11:38
abadger1999ah okay, I understand11:39
abadger1999I was thinking resouce owner was another server -- but it's the entity that owns the resource.11:39
abadger1999got it11:39
puiterwijkcan be a server or a user11:39
puiterwijknow it gets complicated :)11:40
puiterwijkso the client needs this "access token", which grants access to the resource11:40
puiterwijknow there are a few described ways of gaining them11:41
puiterwijkthe first one is an authorization code: the client redirects the user to the authorization server, which authenticates the user and asks for authorization, and then returns the authorization code11:41
puiterwijkthis is NOT usable as access token, it can only be used to request an access token11:42
puiterwijkas such, it can only be used one time11:42
puiterwijkas soon as a token is issued for the authorization code, the authorization code expires, as the client now has an access code11:43
abadger1999puiterwijk: does the authorization code only work to grant a specific access token?11:43
puiterwijkabadger1999: what do you mean?11:43
abadger1999Is the code specific to a certain resource?  Or could I use it for several different resources?11:44
abadger1999For instance, only usable to retrieve my full name from the fas server.11:45
puiterwijkno, the authorization code is specific to the authorization given, and is thus limited to what the resource owner agreed to11:45
abadger1999err... retrieve a token to do that.11:45
abadger1999okay cool.11:45
puiterwijkthe authorization tokens are only meant so that the user can't see the access token11:46
abadger1999puiterwijk: does the authorization server needs to know about the range of tokens or is what token is requested sent to it on demand by the resource server somehow?11:46
puiterwijkabadger1999: yes11:47
puiterwijkokay, let me start from the beginning of the auth-code protocol, as I skipped some important parts ;)11:47
cluecrowdthis the right place to say "localhost.localdomain" wtf?11:47
puiterwijkplease note: this system is primarily used for web applications as client11:47
puiterwijkcluecrowd: that depends on where that is? if it's your own system, I'd go to #fedora11:48
puiterwijkabadger1999: so for example pep8bot with github11:48
puiterwijkabadger1999: so let me use pep8bot as an example11:49
puiterwijk1. I browse to pep8.me11:49
puiterwijk2. pep8 wants to gget access to my repository list (including private)11:49
puiterwijkso: 3. pep8 registers itself with the authorization server and requests an client-id11:50
puiterwijkduring this step, it also provides the server with a list of permissions it would like to have11:50
puiterwijk4. pep8 gets an url from the authorization server to which it should redirect the user to authorize the app11:51
puiterwijk5. pep8 redirects the user to that url11:51
puiterwijk6. the user now arrives at the authorization server, and after logging in can see a list of permissions requested by which app11:52
puiterwijk7. either the user accepts or rejects this list11:52
puiterwijk8.a. the user rejects: he gets returned to the app with an error, and here ends the protocol11:52
puiterwijk8.b. the user accepts: the authorization server generates a new authorization code, and forwards the user back to the app with this authorization code in the request11:53
puiterwijk(from here on, I assume path b was chosen)11:53
puiterwijk9. the app receives the request from the user with the authorization code, and uses it to request an access token from the authorization server11:54
puiterwijk10. the authorization server generates a new access token with the same authorizations the user accepted, and returns this to the app11:55
puiterwijk11. the app stores its access token, and uses this to request the protected resource from the resource server11:55
puiterwijkabadger1999: I hope this clarifies some things?11:56
abadger1999puiterwijk: 12.  the resource server verifies that the access token is valid through some means (could query the authorization server or the authz server could have forwarded the list of valid access tokens to it) ?11:57
puiterwijkabadger1999: correct11:57
abadger1999puiterwijk: cool.  makes sense11:57
puiterwijkor the token could contain the permissions in itself, being signed by the authorization server.11:57
puiterwijkalthough this would make expiring harder, but it is mentioned as a possibility in the spec11:58
puiterwijkokay, so that is just one of the four ways to retrieve an access token.. I told you OAuth is big ;)11:59
puiterwijkabadger1999: you want me to continue these ways to get the access tokens, or do you want me to explain what happens afterwards?11:59
abadger1999hmm.. if you have time, i guess the other ways to get access tokens12:00
puiterwijksure, I have all the time you need ;)12:00
abadger1999cool :-)12:00
puiterwijkthe second way: "Implicit", which is a shortcut of the previous one, where the user gets the access tokens directly12:01
puiterwijkthis is primarily meant if the client is implemented in browser, like a completely browser-side javascript client12:01
puiterwijkas here it doesn't make sense to use the authorization code, as the token will get retrieved by the same system anyway, so they skip that12:02
puiterwijkthe third defined way to retrieve an access token is the "Resource owner password credentials": here the resource owner provides his password to the app, which it uses to retrieve an access token. so here the app still needs the password, but it can throw this away after it receives an access token12:03
abadger1999puiterwijk: would that also be the way a CLI or desktop app would use to get the token?12:03
abadger1999(the implicit way, that is)12:04
puiterwijkabadger1999: could be, but we could also chose the password system, or even the fourth system: "Client credentials"12:04
abadger1999k.  /me listens to the fourth option12:04
puiterwijksorry, /me had misremembered the fourth option12:05
puiterwijkthe fourth is meant if the client is the resource server by itself, to define it can access its own resources by authenticating itself12:06
puiterwijkabadger1999: I would suggest CLI apps to use the "resource owner password credentials" way, and desktop apps to use the implicit way12:07
abadger1999in the third option, where does the username +password go?  directly from the client app to the resource server?12:08
puiterwijkthis is because it's much harder to use a web-service from an CLI client I think12:08
puiterwijkin the third option, the client uses the username+password to request an access token12:08
puiterwijkafter this, the client can forget the username+password, and just use the access token12:08
abadger1999k.  so it still goes to the authz server.12:08
puiterwijkyes, as mentioned: these are the ways to get an access token12:09
puiterwijkall access tokens are provided by the authz server12:09
puiterwijkso every authorization is passed by the authorization on one way or the other12:10
abadger1999for the fourth method; how does it prove that it is the resource server itself?12:10
puiterwijkabadger1999: undefined... :/12:11
abadger1999puiterwijk: okay.  so it could be implemented as "special user+password that represents the auth server", for instance?12:11
abadger1999and then it's really equivalent to the third option?12:12
puiterwijkoh, yep12:12
puiterwijkalthough the "special user+password" represent the client12:12
puiterwijkthe fourth way is meant if FAS would request a resource from FAS12:12
puiterwijk(for example)12:13
puiterwijkso if client == resource server12:13
puiterwijkI think using that fourth way is too much overkill for us for the moment, but still wanted to mention it to be complete ;)12:13
abadger1999yeah -- I'm just trying to figure out when the client would request something from itself and if there's a specialcase in how it needs to auth (or if it's just for the flexibility of letting it auth in a different manner)12:13
abadger1999s/client/resource server/12:14
abadger1999they're client == resource server so the sentence is the same, but it seems clearer if I had said resource server there :-)12:14
puiterwijkit's meant when you have/want real tight seperation between tenants for example, so that the resource server has to get authorization to retrieve information from another tenant ;)12:15
puiterwijkso that one's quite overkill for us12:15
puiterwijkokay, those are the ways to get an access token12:16
puiterwijkOAuth also provides the possibility of "rekeying", or refreshing the token12:17
puiterwijkwith the access token, the authorization server can also provide a refresh token12:17
puiterwijkthen the access token could have a very short validity time, like a week or so, after which it becomes invalid12:18
puiterwijkat this moment, the application can request a new access token by using the refresh token12:18
puiterwijk(and the refresh token itself can ALSO have an expiry date)12:19
puiterwijkand most probably, the refreshed access tokens would have the same authorizations, although they are allowed to have a different authorization-set12:20
abadger1999security-wise, what does a refresh token give you as opposed to just allowing longer validity on the access token?12:21
abadger1999are they supposed to be kept in different places?12:21
puiterwijkabadger1999: it gives you the rekeying12:21
puiterwijkthe token is used to encrypt the signatures12:21
abadger1999or just to ensure that the access is actually being used?12:21
puiterwijkand if you use the same token too much, it might leak too much information (and is suspectable to brute-forcing)12:21
puiterwijkthe refreshing is used so that the application doesn't use the access code for long periods of time, after which it could be cracked12:22
abadger1999okay -- so it's to limit the amount of cyphertext that's possibly intercepted that has been encrypted or signed using a single access token?12:23
puiterwijkand the amount of time the same key is used12:23
abadger1999okay.  it isn't intended to protect against the access token itself being stolen.12:23
abadger1999got it. okay.12:24
puiterwijkand that's the basics of OAuth12:24
abadger1999okay-- so getting back to an earlier question: 12:26
abadger1999[11:46:44] <abadger1999> puiterwijk: does the authorization server needs to know about the range of tokens or is what token is requested sent to it on demand by the resource server somehow?12:26
abadger1999[11:47:04] <puiterwijk> abadger1999: yes12:26
puiterwijkI will scroll back to that logs, as I'm not sure anymore about the context12:26
abadger1999was a that a yes to the authz server knowing ahead of time what tokens it can grant?12:27
puiterwijkabadger1999: I have to say I don't really understand anymore what you mean. could you clarify your question a bit?12:28
abadger1999So the client makes a request to the authz server for resource X, Y, Z for resource owner foo.  Does the authz server have to know ahead of time that it is responsible for authorizing requests for resource X, Y, and Z?12:29
puiterwijkso you want to know if it has to know up-front that it can provide authorization for "full name of puiterwijk" and "ssh key of puiterwijk"?12:30
abadger1999Or can it say "Foo authenticated with me and said it was okay to access these resources so here's an access token.  It's up to you (the client) to find out if the resource server will accept it."12:30
abadger1999puiterwijk: correct.12:30
puiterwijkabadger1999: have to say again... undefined, so we can choose whichever is most fortunate for us12:31
puiterwijkah no, officially this is undefined12:32
puiterwijkbut there is defined that the user has to approve the authorizations it grants12:32
puiterwijkmy interpretation says that means the user should be shown a user-friendly description of the authorizations12:32
abadger1999what is the format of the resource information so that the user can know what they are approving?12:33
puiterwijkofficially, undefined. I would assume the user gets to see a list of permissions, like "file a bug report in bugzilla" and "create an update in bodhi"12:34
puiterwijks/assume/like to see/12:34
abadger1999I'm just wondering if it gives you room  to write a short symbolic name or a one sentence description or a paragraph description.12:34
puiterwijkit gives you roo mfor both12:34
puiterwijks/roo mfor/room for/12:35
abadger1999is oauth intended to be very granular in its permissions?12:35
abadger1999okay -- so it could be "function by function" or it could be "anything this resource server provides"12:35
puiterwijk(sorry about having to say much "undefined"'s, but that was what is meant by that it will produce many non-interoperable clients)12:35
puiterwijkyep, or a mix of both12:36
abadger1999and that's just a question of how the resource server was coded.12:36
abadger1999a client can ask for a set of permissions (give me access to resource X and resource Y).12:36
abadger1999what implementation details are specified about how that works?12:37
abadger1999authz server returns one authorization code that liss all of the permissions?12:37
abadger1999or one for each permission12:37
abadger1999resource server returns one access token or several?12:38
abadger1999cluecrowd: for both of those questions, I assume?12:39
puiterwijkone access token per combination of app and set of permissions12:39
abadger1999puiterwijk: app + client + permissions?12:39
puiterwijkabadger1999: sorry, client + permissions12:39
abadger1999ah okay.12:40
puiterwijkone token could give access to multiple apps12:40
abadger1999oh -- i see my confusion. I don't think we strixtly defined "app"12:40
abadger1999are you using it to mean client?12:41
puiterwijk"app" = "resource server"12:41
puiterwijkin the last case12:41
puiterwijkone token is bound to a single client, but could grant access to multiple "resources" on multiple "resource servers", as long as all resources are owned by the same resource owner12:42
puiterwijkor at least12:42
puiterwijkdoesn't have to be the same resource owner12:43
puiterwijkbut the resource owner needs to have the required permissions to grant that set of permissions12:43
abadger1999okay -- how does that work?  the client combines access tokens it received from multiple resource servers into one?12:43
puiterwijkno, it received the access token from the authz server12:44
abadger1999(I'm not sure we'll need this... but I'm not sure how this works)12:44
puiterwijkso for example: if an application requested it, I could grant it a token to give it the permissions "create an update for sslsplit on bodhi" and "update the ssh key for puiterwijk in FAS", in a single token12:45
cluecrowdthe token is just a blob, the permissions associated with it are server side, the client doesn't what it has until it tries to do something12:46
cluecrowdthen its either allowed or not12:46
abadger1999i thought the authorization code came from the authz server.  then that was used to request an access token from the resource server?12:46
puiterwijkabadger1999: no, both authorization codes and access tokens are provided by the authz server12:47
puiterwijkand then the resource server checks the token (either by contacting the authz server or by checking the list the authz server sent to him, or whatever)12:47
puiterwijkbut all tokens and codes are granted by the authorization server12:48
abadger1999so that's how the client can have an access token that grants permissions on multiple resource servers.  got it.12:49
puiterwijkokay, great :)12:49
abadger1999so a client should have one access token from all the authz servers that it talks to (usually, ther'd be only one) each token would grant a set of permissions that the user had authorized for all the resource servers that acknowledge that particular authz server as being canonical for them.12:51
abadger1999does that sound right?12:52
puiterwijkyep, indeed12:52
puiterwijk(although the word "canonical" makes me feel bad :))12:52
abadger1999hehe :-)12:52
puiterwijklet's call it "being authorative for them", right? :)12:53
abadger1999puiterwijk: the mapping of access token to permissions is not contained in the token, correct?  it's something that the authz server negotiated with the resource owner and then the authz server tells the resource servers about?12:54
puiterwijkabadger1999: could be both12:54
puiterwijkbut we should prefer that way indeed12:54
abadger1999puiterwijk: okay, I think this is pretty clear in my head now.12:55
abadger1999so some questions about how we might want to use this in fedora...12:55
puiterwijkthe other would be to encode it in the token, and sign it, but as I mentioned earlier that would make premature expiration harder12:55
abadger1999does it make sense to conceptually separate a session authorization from this concept?12:56
puiterwijk"session authorization" being a web-session where the user signed in?12:57
abadger1999in my mind, sessions last minutes to hours and are intended to let the server reasonably assume that this user is the same one who signed in a "little while ago".12:57
abadger1999puiterwijk: yeah -- that's where it would come from I think.12:57
abadger1999some web sites (like bz.redhat.com) seem to keep a session around for months but... I kinda thnk that's an abuse of sessions.12:58
puiterwijkaccess tokens are mostly days to weeks, and are intented to let the server assume that this is the same app that got permissions12:58
abadger1999puiterwijk: something that lasts for weeks to years seems like it's better suited to access tokens like this.12:58
puiterwijkI kind-of-agree12:59
puiterwijkexcept that that's why we have refresh tokens;)12:59
puiterwijkbut otherwise: yeah12:59
abadger1999puiterwijk: <nod>  so does this sound like an okay conceptual split to you?  or is it not beneficial to split this up like this?12:59
puiterwijkwell, it does, but to me sessions are not just "short-term tokens": sessions are something where we know the user is currently controlling everything13:00
puiterwijka token is an authorization given by the user to the app keeping the token to perform a specific set of actions on his/her bahalf13:00
abadger1999puiterwijk: ah. okay so conceptually sessions prove the user is present.  access tokens show that the user has granted this client permission to perform an action for them.13:01
abadger1999the user could be present using the client or not present. but the idea of the client sitting between the user and the resource server is the important distinction ?13:02
puiterwijkthe idea is that the user is not directly in control of what's happening, but that he delegated a set of tasks to a client13:03
puiterwijkthe fact that he might be influencing it isn't taken into consideration13:03
puiterwijkfor example with fasClient: we delegate the creation of users and updating of ssh keys to fasClient13:04
puiterwijkbut I do not delegate responding on a bugzilla ticket to bugzilla13:04
abadger1999right.  where it gets grey to me is how we want to categorize something like pkgdb-cli13:04
abadger1999or /usr/bin/bugzilla (from python-bugzilla)13:05
puiterwijk/usr/bin/bugzilla would be delegating to me, as I'm not accessing the resource server directly13:05
puiterwijkbut that's how I see it. I do agree with you that it is a bit of a grey area13:06
abadger1999puiterwijk: well... but as we talked baout the other night, you aren't doing so directly when you browse to the website in firefox either.13:06
abadger1999but I do agree that it is nice to have less things that you have to trust :-)13:06
puiterwijkI personally would go for tokens for CLI tools as well, as you might script those13:07
abadger1999puiterwijk: is there a problem with having a library that allows you to use either method?13:08
puiterwijkabadger1999: there wouldn't be a problem, but it would be hard to build and maintain, I'd think13:08
puiterwijkI would think that we should just use tokens for that, but maybe tokens with a validity of an hour or so13:08
abadger1999tangent -- when using a token to communicate with a server, should a session be issued?  Or should a session never be issued for that use case?13:09
puiterwijkI think you mostly use APIs in a stateless way, so I'd say: no sessions13:09
abadger1999puiterwijk: the hting is... I think I would want to have different permissions if I was running the cli client myself vs having it run from cron.13:09
abadger1999well that's one of the things.13:09
puiterwijkabadger1999: +1 on the different permissions13:10
puiterwijkand about the sessions for tokens:13:10
abadger1999the other one is that I'd want to protect the credentials for the one I run from the cli differently.13:10
puiterwijk+1 on that as well13:10
abadger1999ie: if I can build and push packages with the cli, I might want to use my otp to confirm it.13:10
<-- abompard has left this server (Ping timeout: 252 seconds).13:10
puiterwijkabout the sessions: I would not care if there is used any session, as long as the authentication status is not mentioned in it13:11
abadger1999but if I have a cron job that checks for builds of packages that are deps of packages I own, I'd be fine with it using an access token saved on the filesystem.13:11
puiterwijkbut for this, we could also use tokens with different validity periods13:12
abadger1999puiterwijk: by authentication status, you mean whether it's valid or expired?  Or whether something else?13:12
puiterwijklike a 5-minutes (or 1-hour, or whatever) token for CLI, approximating sessions, and a 1-month (or longer) token for the cron job13:12
puiterwijkabadger1999: any information on the token or any information on whether the client was authenticated13:13
puiterwijkso I would be fine with storing things like "previous-action" in a session, but not to store "authenticated-as: puiterwijk" or "permissions: create-update,view-updates,..." in a session13:13
puiterwijk(please note that this is my personal preference)13:14
puiterwijkthis is primarily because the client can send the token on any request, and we might want to check its validity on every request13:14
abadger1999ah... so when i'm talkign about sessions... I guess I'm rally just talking about the value that identifies you to the server.13:15
abadger1999*I guess I'm really13:15
puiterwijkah, then I wouldn't be a proponent of that13:15
abadger1999the value is basically a secret key (and perhaps some form of uid)13:15
puiterwijkyeah, I understand13:15
puiterwijkbut what would be the advantage?13:15
puiterwijkthen the resource server needs to check that secret key, instead of the token13:16
puiterwijkbut it still needs to check it13:16
puiterwijkso I don't see the advantage of using that13:17
abadger1999<nod> I'm trying to figure that out.  Is there a value in having a different mechanism to show "User is present and interacting with the resource server" vs "User has delegated permission to this client to act on their behalf"13:17
puiterwijkah, yeah, there could be value13:18
puiterwijknamely: if the user is present, the permissions wouldn't need to be checked as tightly13:18
puiterwijkso if the user is present we might created an "*@*" permissions token13:18
puiterwijk(so: every permission on every resource server)13:18
puiterwijkbut as this could be done with tokens, I would not see any reason to support both13:19
puiterwijkthe only advantage would be that it saves a few roundtrips to the authz server, but we would just have to make that very efficient anyway13:20
abadger1999<nod>  So same mechanism but tokens that have different permissions and we treat in different ways.13:20
puiterwijkwe treat them the same, but just a "*@*" permission instead of a real list of permissions13:21
abadger1999by treat differently... I meant the client would need  to know -- this is a token that I should not automatically save to disk, for instance.13:21
puiterwijkah, yeah, agreed then13:21
puiterwijk(hmmm, I might want to look into when to use "then" and when to use "than" in English :))13:22
abadger1999(heh, most english speakers have given up figuring out the distinction ;-)13:22
puiterwijk(okay, I know now, sorry if I evr did that wrong :))13:22
puiterwijk(well, according to the site I just saw "than" is comparisons, and "then" is time or order)13:23
puiterwijkbut anyway, I agree on that13:24
abadger1999puiterwijk: so... some things to think about... how hard will it be to create this infrastructure?  (write an authorization server.  Add permissions to apps [can cheat initially and have a permission for the whole app].  Have the app talk to the authorization server to confirm whether the client that presented a token is allowed to perform the desired action)13:25
puiterwijkabadger1999: with my recent experience on OpenID, I think I could implement this pretty easily13:26
puiterwijkboth the server-side and a library for python to use it13:26
[Notice] -GitHub150 to #fedora-apps- [fedmsg] ralphbean created feature/tweet-as-hub (+2 new commits): http://git.io/_NyKVA13:26
[Notice] -GitHub150 to #fedora-apps- fedmsg/feature/tweet-as-hub 8aefb3c Ralph Bean: Some PEP8.13:26
[Notice] -GitHub150 to #fedora-apps- fedmsg/feature/tweet-as-hub 9d2ab13 Ralph Bean: Reorganize fedmsg-tweet into a single-purpose hub like the other daemons.13:26
abadger1999puiterwijk: Okay.  I'm liking this then.13:26
puiterwijkabadger1999: okay, do I have permission to start on it then? ;)13:27
abadger1999puiterwijk: next step -- write up the important bits and ask whether other people like it?13:27
puiterwijkat least some basic showcase, so I can show something13:27
abadger1999puiterwijk: I can summarize what we talked about here and send it to the mailing list.13:27
puiterwijkabadger1999: that would be nice yeah13:27
abadger1999puiterwijk: yeah -- if you want to get started on coding, I think this is desirable.13:27
puiterwijkand as I said: I would be glad to take "control" in te FAS-OAuth project as well, if you would let me :)13:28
abadger1999puiterwijk: yep,  yo're welcome to take ownership of that too :-)13:28
puiterwijkhmmm, "control" sounds too powerful13:28
puiterwijkokay, thanks :)13:28
abadger1999"responsibility for"   ;-)13:28
puiterwijkyeah, that's what I was looking for, thanks :)13:28
[Notice] -GitHub43 to #fedora-apps- [fedmsg] ralphbean opened pull request #124: Feature/tweet as hub (develop...feature/tweet-as-hub) http://git.io/m3KGPQ13:29
abadger1999puiterwijk: oh one other thing -- skvidal mentioned that one thing he liked about api tokens is that a compromised token doesn't give you anywhere near the same amount of access as a compromised fas password.13:29
abadger1999we'll have to think about how that interacts with our "*@*" tokens.13:30
puiterwijkabadger1999: that's correct, since you could make sure a token never has the possibility to change a password13:30
puiterwijkyou could say that even *@* does not have permissions to change password/email in FAS13:30
abadger1999puiterwijk: <nod>  yeah, I'd agree with that.13:30
puiterwijkand you won't be able to use tokens to login to the web interfaces, so you can't use that either with just a token :)13:31
abadger1999puiterwijk: he was thinkng in terms of an api token for copr wouldn't give you access to bodhi or pkgdb as well, though.  we'd have to think about that as well.13:31
puiterwijkwell, that's because a token has a specific set of permissions13:32
abadger1999puiterwijk: yeah -- but my vision is that anything you can do on the web ui (with limits like password changing) you can do via the api :-)13:32
puiterwijkand every permission is for a specific resource server13:32
puiterwijkyeah, I agree. but then a token would have to be requested for all permissions an app would want to do13:32
puiterwijkbut with "permissions", you won't have something like "view", but rather you'd have "bodhi.view" and "copr.view.builds" and "copr.submitbuild"13:34
puiterwijkso a permission is app-specific13:34
abadger1999puiterwijk: <nod>  But we were talking about -- if the user has just logged in; how could we represent that?13:35
puiterwijkso it's not that you have permission "edit" for "copr,bodhi", but rather you would have "copr.edit,bodhi.edit"13:35
puiterwijkabadger1999: what do you mean?13:35
abadger1999puiterwijk: well. when were you thinking we'd use the "*@*" token?13:36
puiterwijkif the user is present at the machine13:37
puiterwijkah, I think you mean that tokens provide more security, but a "*@*" token doesn't?13:37
abadger1999how do we want to determine that?13:37
puiterwijkI agree on that, but I can't see any real ways to prevent that13:37
puiterwijkexcept for giving the user to enter his password if the token requires more permissions13:37
abadger1999so we want to allow the user to do all their business without asking them to reconfirm their identity all the time.  But we also don't want that token to be left lying around to be stolen by someone.13:38
puiterwijkso that it's a "*@*/require-password-on-extending"13:38
puiterwijkthat's why I suggested an expiration time of a short time13:38
cluecrowdlike kerberos13:38
* puiterwijk doesn't see where kerberos fits in, as that uses a key-requesting-key system...13:39
abadger1999puiterwijk: <nod>  So something like we currently have for session cookies?  Short time period (no more than 24 hours, hopefully much less).  and when it expires, user has to reenter password/otp to get a new "*@*" token?13:39
puiterwijkabadger1999: what I would suggest: issue tokens with a validity time of +- 5 minutes, and refresh tokens of about 15 or so13:39
puiterwijkyes, indeed13:40
abadger1999puiterwijk: wfm.13:40
puiterwijkabadger1999: "wfm"?13:40
abadger1999works for me.13:40
puiterwijkah, ok, cool :)13:40
* abadger1999 wonders if we could get away with requiring an otp to get a '*@*' token13:40
* puiterwijk also wonders the same13:41
puiterwijkabadger1999: shall I create the fas-oauth repos on fh.o and github? :)13:41
abadger1999puiterwijk: go for it :-)13:41
puiterwijk\o/ just when my previous project is about to hit production, I get a next nice project :)13:42
puiterwijk|cuepuiterwijk: Error: "o/" is not a valid command.13:42
abadger1999puiterwijk: you only need to create the fedorahosted one if you want it ... I think most of us have become happy with the github repos :-)13:42
abadger1999hehe :-)13:42
puiterwijkpuiterwijk|cue: part #fedora-apps13:42
<-- puiterwijk|cue has left this channel ("puiterwijk").13:42
puiterwijkokay, I might want to reconfig it tto use another prefix :)13:43
puiterwijkbut I prefer fedorahosted, because there I can show my responsibility, because I'll be the only one able to commit.. muahaha :)13:43
abadger1999hehee :-)13:43
puiterwijkfor FAS-OpenID, the fh.o is the main copy, and github is just a mirror :)13:44

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!